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KNOWLEDGE-BASED  INTEGRATED  INFORMATION  SYSTEMS 
DEVELOPMENT  METHODOLOGIES  PLAN 


About  This  Volume 


V, 


This  volume  describes  the  Integrated  Information  System  Evolution  Environment 
(IISEE)  which  is  a  structured  approach  for  the  strategic  planning,  tactical  planning, 
requirements  definition,  design,  construction,  implementation,  and  maintenance  of 
large  scale  distributed,  heterogeneous  integrated  information  systems.  This 
approach  is  designed  to  enable  system  developers  in  the  Air  Force  and  its  contractor 
community  to  evolve  their  current  systems  into  a  unified  framework. 

The  overall  goal  of  the  IISEE  thrust  is  to  establish  a  structured  systems  development 
approach  consisting  of  methodologies,  methods,  tools,  techniques,  and  practices 
which  can  improve  productivity  of  participants,  and  reduce  cost  and  time  required 
for  integrated  information  systems  development.  The  IISEE  strategy  has  been 
designed  keeping  in  view  the  objectives  of  the  Integrated  Design  Support  System 
(IDS)  Program  of  the  Air  Force.  The  latter  program  encompasses  all  issues  relating 
to  capture,  management,  and  communication  of  product  technical  data  from  its 
initial  creation  in  design,  through  realization  in  manufacture,  to  logistics 
operations.  •  .  ,  — —  ...  '  — 

The  work  described  in  this  volume  haaheen  jointly  conducted  by  several  contractors 
and  subcontractors.  The  individual  inputs  have  been  edited  and  consolidated  by  a 
research  team  led  by  Richard  J.  Mayer  of  the  Knowledge  Based  Systems  Laboratory 
at  Texas  A&M  University. 
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SERIES  EDITORS’  NOTE 


This  book  is  one  of  eight  volumes  published  by  MIT  as  part  of  the  Knowledge-Based 
Integrated  Information  Systems  Engineering  Project  (KBIISE).  In  order  to 
appreciate  the  papers  in  this  book,  it  is  necessary  to  be  aware  about  the  theme  of  the 
KBIISE  project,  its  major  objectives,  and  the  different  documents  that  summarize 
the  research  accomplishments  to  date. 

Goal 


The  primary  goal  of  the  KBIISE  project  is  to  integrate  islands  of  disparate 
information  systems  that  characterize  virtually  all  large  organizations.  The  number 
and  the  size  of  these  islands  has  grown  over  years  and  decades  as  organizations  have 
invested  in  an  increasing  number  of  computer  systems  to  support  their  growing 
reliance  on  computerized  data.  This  has  made  tne  problem  of  integration  more 
pronounced,  complex,  and  challenging. 

The  need  for  multiple  systems  in  large  organizations  is  dictated  by  a  combination  of 
technical  reasons  (such  as  the  desired  level  of  processing  power  and  the  amount  of 
storage  space),  organizational  reasons  (such  as  each  department  obtaining  its  own 
computer  based  on  its  function),  and  strategic  reasons  (such  as  the  level  of 
reliability,  connectivity,  and  backup  capabilities).  Further,  underlying  trends  in  the 
information  technology  area  have  led  to  a  situation  where  most  organizations  now 
depend  on  a  portfolio  of  information  processing  machines,  ranging  from  mainframes 
to  minicomputers  and  from  general  purpose  workstations  to  sophisticated 
CAD/CAM  systems,  to  support  their  computational  requirements.  The  tremendous 
diversity  and  the  large  size  of  the  different  systems  make  it  difficult  to  integrate 
these  systems. 

Key  Participants 

The  above  problem  is  becoming  increasingly  evident  in  all  large  government 
agencies  and  in  large  development  programs.  In  the  fall  of  1986,  the  U.S.  Air  Force 
(USAF)  and  the  Transportation  Systems  Center  (TSC)  of  the  U.S.  Department  of 
Transportation  approached  M.I.T.  to  conduct  and  to  coordinate  research  activity  in 
this  area  in  order  "to  develop  the  framework  for  a  comprehensive  methodology  for 
large  scale  distributed,  heterogeneous  information  systems  which  will  provide:  (i) 
the  necessary  structure  and  standards  for  an  evolving  top  down  global  framework; 
(ii)  simultaneous  bottom  up  systems  development;  and  (iii)  migratory  paths  for 
existing  systems.” 


Both  USAF  and  TSC  provided  sustained  assistance  to  members  of  our  research  team. 
In  addition,  Citibank  and  IBM  provided  some  funds  for  research  in  very  specific 
areas.  One  advantage  of  our  corporate  links  was  the  opportunity  to  analyze  and  to 
generate  case  studies  of  actual  decentralized  organizational  environments. 
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The  research  sponsors  and  MIT  agreed  that  in  order  to  deal  with  the  heterogenity 
issue  in  a  meaningful  way,  it  was  important  that  a  critical  mass  of  influential 
individuals  participate  in  the  development  of  solutions.  Only  through  widespread 
discussion  and  acceptance  of  a  proposed  strategy  would  it  become  feasible  to  deal 
with  the  major  problems.  For  tnese  reasons,  a  Technical  Advisory  Panel  (TAP)  was 
constituted.  Nominees  to  the  TAP  included  experts  from  academic  and  research 
organizations,  government  agencies,  computer  companies,  and  other  corporations. 
In  addition,  several  subcontractors,  the  primary  one  being  Texas  A&M  University, 
provided  assistance  in  specific  areas. 
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The  scope  of  the  work  included'(i)  technical  issues;  (ii)  organizational  issues;  and  (iii) 
strategic  issues.  On  the  basis  of  exploratory  research  efforts  *n  all  these  areas,  24 
technical  reports  were  prepared.  Eighteen  of  these  reports  were  generated  by  MIT 
research  personnel,  ana  their  respective  areas  of  investigation  are  summarized  in 
the  figure  on  the  opposite  page. 

The  five  technical  reports,  not  represented  in  the  figure,  are  as  follows: 

#1.  Summary. 

#2.  Record  of  discussions  held  at  the  first  meeting  of  the  Technical  Advisory  Panel 
(TAP)  on  February  17, 1987. 

#3.  Consolidated  report  submitted  by  Texas  A&M  University. 

#21.  Annotated  Bibliography. 

#23.  Record  of  discussions  held  at  the  second  meeting  of  the  Technical  Advisory 
Panel  (TAP)  on  May  21  and  22, 1987. 

#24  Contributions  received  from  members  of  the  TAP  highlighting  their  views  on 
various  aspects  of  the  problem. 

All  the  24  technical  reports  have  been  edited  and  reorganized  as  an  eight-volume 
set.  The  titles  of  the  different  volumes  are  as  under: 

1.  KNOWLEDGE-BASED  INTEGRATED  INFORMATION  SYSTEMS  ENGINEERING- 
HIGHLIGHTS  AND  BIBLIOGRAPHY 

2.  KNOWLEDGE-BASED  INTEGRATED  INFORMATION  SYSTEMS  DEVELOPMENT 
METHODOLOGIES  PLAN 

3.  INTEGRATING  DISTRIBUTED  HOMOGENEOUS  AND  HETEROGENEOUS  DATABASES  - 
PROTOTYPES 

4.  OBJECT-ORIENTED  APPROACH  TO  INTEGRATING  DATABASE  SEMANTICS 

5.  INTEGRATING  IMAGES,  APPLICATIONS,  AND  COMMUNICATIONS  NETWORKS 

6.  STRATEGIC,  ORGANIZATIONAL,  AND  STANDARDIZATION  ASPECTS  OF  INTEGRATED 
INFORMATION  SYSTEMS 

7.  INTEGRATING  INFORMATION  SYSTEMS  IN  A  MAJOR  DECENTRALIZED 
INTERNATIONAL  ORGANIZATION 

8.  TECHNICAL  OPINIONS  REGARDING  KNOWLEDGE-BASED  INTEGRATED 
INFORMATION  SYSTEMS  ENGINEERING 

Volume  2  contains  the  report  submitted  by  Texas  A&M  and  Volume  8  highlights  the 
views  of  members  of  the  TAP.  Activities  described  in  the  other  6  volumes  have  been 
conducted  at  MIT. 
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•  Evolutionary  Approaches 

(#4  Madnick,  Wang) 

•  Prototype  Distributed  Databases 

--  Homogeneous  (#11  Gref) 

--  Heterogeneous  (#5  Bhalla,  Prasad, 

Gupta,  Madnick) 

•  Integrating  Image  Databases  and 
Knowledge 

--  Image  Databases  (#17  Apostle;  #18  Kim) 
--  Application  Knowledge  (#10  Habeck) 

•  Object-Oriented  Approach  to 
Integrating  Database  Semantics 
--  Concepts  (#20  Cooprider) 

--  Implementation  (#9  Levine) 

--  Application  (#13  Pocaterra) 

•  Communications 

--  Integrated  Comm  with  Database 
(#16  Kennedy) 

--  Internet  Integration 
(#15  Yoo) 
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•  Inter-organizational  Networks 

(#8  Nohria,  Venkatraman) 

•  Standardization 

-  Focused  Standards 
(#19  Trice) 

-  PDES  Case  Study 
(#7  Kallel) 
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The  key  to  making  an  effective  Integrated  Information  System  Evolution  Environment  (IISEE) 
is  to  develop  a  common  core  of  methods  which  are  modular  and  which  interlock  in  a  consistent 
fashion  to  cover  the  entire  life  cycle.  Surrounding  this  cover,  a  set  of  special  techniques  must 
be  developed  for  dealing  with  the  special  characteristics  of  the  organization,  the  problem  area, 
and  the  application  technology 

The  Integrated  Design  Support  System  (IDS)  Program  is  focused  on  the  capture,  management, 
and  communication  of  product  technical  data  from  its  initial  creation  in  design,  its  realization 
in  manufacture,  through  logistics  operations.  The  system  encompasses  several  hundreds  of 
contractors,  and  many  millions  of  line  of  program  code.  The  enormity  of  the  task  is  somewhat 
mitigated  by  the  fact  that  only  the  critical  product  data  needs  to  be  controlled 

The  approach  taken  in  IDS  is  to  implement  three  schema  architecture  utilizing  commercially 
available  software  mechanisms  to  the  maximum  extent  possible.  Enterprise  information 
control  is  accomplished  via  the  establishment  of  a  "conceptual  schema”  and  an  executive 
control  system.  The  conceptual  schema  contains  a  definition  of  the  enterprise  information 
management  and  control  rules.  The  executive  control  system  validates  each  transaction 
against  these  rules. 

Two  models  of  the  system  development  process  have  been  developed.  The  Information  System 
Evolution  Process  model  (ISEP-O)  is  aimed  at  systematically  describing  how  to  build  and  use 
Information  Systems  Integration  shells,  like  an  IDS  shell  The  Integrated  Design 
System/System  Development  Process  model  (IDES/SDP-O)  is  designed  to  help  describe  the 
process  of  assimilation,  customization,  and  utilization  of  an  IDS  shell.  The  IDES/SDP-0  model 
has  been  developed  down  to  the  second/third  level  of  decomposition  and,  in  places,  extended 
further  with  a  very  detailed  node  index  These  two  models  can  help  large  organizations  reduce 
the  complexities  involved  in  integrating  multiple  large  distributed  databases  together. 
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Chapter  1 

Management  Summary 


1.1  Introduction 

The  Air  Force  Integrated  Design  Support  System  (IDS)  represents  a  major  evolutionary  step 
in  information  resource  management.  The  evolution  from  stand  alone  applications  to  inte¬ 
grated  information  environments  has  caused  the  recognition  of  a  need  to  provide  a  means  of 
acquiring  and  using  this  new  technology.  An  integrated  methodology  to  support  the  major 
roles  and  activities  of  these  new  systems  is  required.  The  methodology  must  include  spe¬ 
cific  methods,  automated  tools,  integrating  frameworks  (how  to  procedures),  and  automated 
environments.  By  major  roles  we  mean  management,  engineering,  construction,  and  main¬ 
tenance.  By  activities  we  include  planning,  definition,  design,  realization  and  maintenance. 
The  term  “new  systems”  covers  the  information  integration  utilities  themselves,  the  new 
applications  developed  under  these  frameworks,  and  the  legacy  systems  which  must  be  in¬ 
terfaced  to  the  new  order.  This  project  was  initiated  with  the  objective  of  uncovering  what 
the  current  industry  practitioners  (those  attempting  to  build  and  implement  information 
integrated  systems)  needs  were  relative  to  such  an  integrated  methodology.  These  needs 
were  then  translated  into  specific  requirements.  In  many  cases  these  requirements  represent 
shortfalls  in  the  current  “applications  engineering”  based  methods  and  tools.  Based  on  these 
requirements  and  an  understanding  of  the  current  state  of  the  art  in  software  development 
methods  and  tools  we  established  a  concept  for  an  Integrated,  Information  System  Evolu¬ 
tion  Environment  (USEE).  A  program  for  the  development  of  this  concept  from  the  current 
base  of  methods  and  tools  was  established  including  project  descriptions,  budgets,  and  tim¬ 
ings.  These  results  hopefully  will  serve  as  a  basis  for  the  establishment  of  a  research  and 
development  program  to  produce  the  technology  needed  for  an  organization  (commercial  or 
government)  to  implement  and  evolve  an  information  integrated  solution  to  its  current  and 
future  data  needs. 
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CHAPTER  1.  MANAGEMENT  SUMMARY  8 

1.2  Background 

Establishment  of  a  complete  System  Development  Methodology  (SDM)  is  in  itself  a  complex 
system  development  process.  In  fact,  several  effective  analogies  can  be  drawn  between  a 
system  development  methodology  and  developing  a  large  software  system.  Just  as  there  are 
features  and  capabilities  of  a  large  software  system  which  only  a  few  (possibly  only  one)  users 
need,  there  will  be  capabilities  of  an  SDM  which  are  only  needed  in  a  particular  application 
development  arena.  Thus,  an  information  system  developer  working  in  the  implementa¬ 
tion  of  a  factory  control  system  (within  a  three  schema  architecture  concept  like  IDS1)  will 
have  slightly  different  methodological  needs  than  a  developer  of  an  engineering  data  control 
system. 

The  key  to  making  an  effective  Integrated  Information  System  Evolution  Environment 
(IISEE)  for  IDS  is  to  develop  a  common  core  of  methods  which  are  modular  and  which 
interlock  in  a  consistent  fashion  to  cover  the  entire  life  cycle.  Surrounding  this  core,  there 
must  be  a  set  of  special  techniques  for  dealing  with  the  peculiarities  of  the  users  organiza¬ 
tion,  a  specific  problem  area,  or  an  application  technology.  Thus,  when  a  particular  person 
approaches  the  IISEE  he  will  find  both  the  common  core  which  will  insure  that  the  results  of 
his  development  efforts  will  be  information  integratable  with  the  IDS,  and  specific  methods 
which  allow  him  to  deal  with  the  particular  problems  unique  to  his  own  development  efforts. 

Almost  all  methods  in  widespread  use  today  have  evolved  from  engineering  practice.  In 
fact,  a  method  can  be  viewed  as  a  formalization  of  a  commonly  used  (successful)  engineering, 
management,  production  or  support  technique.  Formalism  is  important  because  it  allows  the 
transition  of  the  technique  to  other  application  areas;  it  allows  one  to  define  the  limitations 
of  the  application  of  a  technique,  and  it  facilitates  the  interface  to  other  techniques.  In  the 
early  books  on  structured  programming,  for  example,  a  question  often  posed  was  “What 
is  the  difference  between  what  an  “expert”  programmer  does  and  what  the  methodology 
suggests?”  The  conclusion  was  always  that  there  is  no  difference.  Rather  the  method  was 
supposed  to  assist  in  bringing  all  the  programmers  up  to  the  level  of  quality  and  productivity 
of  the  expert  programmer. 

Another  case  in  point  is  to  remember  that  structure  charting  and  data  flow  diagramming 
(which  Constantine  developed  and  Yourdon  has  popularized)  were  developed  by  studying 
over  100  business  application  systems  at  IBM.  Larry  Constantine  interviewed  the  developers 
and  examined  the  maintenance  and  modification  histories  of  the  applications.  From  this  base 
he  distilled  a  methodology  which  he  felt  captured  the  “best  practice”  from  this  experience. 
The  effectiveness  of  the  methods  in  the  structured  design  methodology  has  been  enhanced 
over  the  years  by  additional  techniques  and  automation  support,  but  the  basic  concepts  have 
remained  unchanged.  It  is  also  interesting  to  note  that  these  structured  design  techniques 
have  been  shown  to  work  poorly  in  such  areas  as  real  time  control  and  transaction  based 
systems.  One  reason  for  this  poor  performance  is  probably  the  fact  that  the  original  set 

1 Integrated  Design  Support  System  (see  Section  1.5  of  this  report) 
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of  systems  which  Constantine  studied  did  not  include  any  systems  of  this  type.  Thus,  it 
should  be  remembered  that  any  methodology  (formal  encoding  of  good  practice)  designed 
to  support  a  development  activity  does  not  say  anything  about  that  activity  in  general.  It 
only  says  that  performing  that  activity  within  a  particular  context  provides  good  results  if 
a  certain  method  is  followed. 

The  existing  IDEF  theories  and  the  SDM,  which  evolved  from  the  ICAM  experience,  were 
also  evolutions  of  previous  methods.  IDEFO  is  a  direct  adaptation  of  SADT,  which  itself 
evolved  from  cell  modeling  techniques  during  the  development  of  the  AFCAM  architecture 
in  1972.  IDEFl  evolved  from  relational  (Chen),  network  (Bachman)  and  hierarchical  data 
modeling  and  database  design  concepts.  IDEF2  evolved  from  the  QGERT,  SLAM,  and  OFD 
lineage  of  network  based  system  dynamics  modeling  languages.  The  SDM  established  in  the 
Air  Force  ICAM  project  1701  was  based  on  the  ICAM  experience,  and  the  experience  of 
the  industry  coalition  in  developing  manufacturing,  design  and  defense  weapons  systems. 
Unfortunately,  the  available  experience  base  in  1981  did  not  include  extensive  integrated 
information  systems  development  experience.  Thus,  while  the  basic  concepts  axe  solid,  there 
are  many  specific  integration  issues  or  decisions  that  developers  who  are  doing  IDS  devel¬ 
opments,  must  address  which  are  not  supported  in  the  current  modeling  or  development 
methodologies. 

Four  years  have  passed  since  SDM  ICAM  Project  1701  was  completed,  and  the  IDEF 
techniques  have  been  frozen  for  seven  years.  During  this  time  an  enormous  experience  base 
has  been  established  in  the  use  of  these  products  to  support  the  development  of  integrated 
information  systems.  Many  contractors,  and  private  industry  users  have  developed  exten¬ 
sions  to  the  basic  methods.  In  this  report  we  have  tried  to  identify,  collect,  and  an. lyze,  the 
experience  of  these  system  developers  and  their  method  extensions  to  provide  the  basis  for 
our  proposed  plan.  The  plan  reflects  the  fact  that  significant  improvements  over  the  existing 
methods  can  be  achieved  with  little  more  than  a  formalization  and  method  integration  effort. 
During  the  last  four  years  significant  research  results  from  the  Artificial  Intelligence  commu¬ 
nity  have  emerged  which  offers  the  possibility  of  both  improved  techniques  for  research  in 
methodology  development  and  new  software  tools  for  building  automated  support  for  SDM 
and  IDEF  users. 

1.3  Project  Goals  and  Objectives 

The  following  paragraphs  summarize  the  objectives  and  goals  of  this  effort.  The  goals  were 
based  on  coalition  experience  with  methodology  development,  experience  of  the  DoD  and 
aerospace  community  in  the  use  of  current  system  development  methodologies  and  IDEF 
modeling  methods,  and  the  experience  of  the  IDS  implementation  activities  at  Rockwell 
International. 

Objective 
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The  primary  objective  of  this  effort  was  to  provide  technical  support  for  establishing  a  re¬ 
search  plan  for  the  development  of  “a  structured  approach  for  the  strategic  planning,  tactical 
planning,  requirements  definition,  design,  construction,  implementation,  and  maintenance” 
of  large  scale  distributed,  heterogeneous  integrated  information  systems.  For  the  remainder 
of  this  document  the  structured  approach  will  be  referred  to  as  the  Integrated  Information 
System  Evolution  Environment  (USEE). 

Goals  of  the  “IISEE  for  IDS”  Thrust 

The  driving  force  behind  USEE  objectives  and  goals  is  the  recognition,  by  the  United 
States  Air  Force,  and  the  coalition  members  of  the  Integrated  Design  Support  System  (IDS) 
development  team,  that  for  the  IDS  concept  to  be  transitioned  into  widespread  use  an  USEE 
must  be  established  which  would  allow  system  developers  in  the  Air  Force  and  its  contrac¬ 
tor  community  to  evolve  their  current  systems  into  an  IDS  framework.  This  evolution  will 
usually  involve:  modifications  to  existing  systems,  replacement  of  existing  systems,  and/or 
the  development  of  new  systems.  During  the  course  of  the  IDS  development,  elements  of  the 
ICAM  SDM  methodologies,  and  particularly  the  IDEF  modeling  methods  have  been  exten¬ 
sively  applied.  This  application  experience  (as  well  as  the  experience  of  many  other  industry 
and  government  users)  has  uncovered  voids  in  the  original  ICAM  SDM,  its  component  meth¬ 
ods  and  in  the  availability  of  automated  support  for  the  development  process.  It  is  evident 
that  the  time  is  right  for  continuation  of  the  SDM  and  IDEF  methods  development.  It  is 
also  clear  that  such  developments  would  be  useful  not  only  within  the  context  of  IDS  goals 
but  also  for  several  other  major  DoD  programs.  Such  a  development  represents  a  large  scale 
effort,  exceeding  the  capacity  of  any  one  program.  Thus,  staged  funding  must  be  acquired 
over  several  years  from  a  variety  of  organizations. 

The  overall  goal  of  IISEE  thrust  is  to  establish  a  structured  systems  development  ap¬ 
proach  consisting  of  methodologies,  methods,  tools,  techniques,  and  practices  which  can  be 
used  to: 

1.  Insure  the  success  of  integrated  information  systems  development; 

2.  Increase  the  productivity  of  the  project  teams  involved  in  systems  development; 

3.  Improve  the  quality  of  the  life  cycle  products  of  the  development  team; 

4.  Reduce  cost  and  time  required  for  integrated  information  system  developments; 

1.4  Organization  of  the  Report 

This  report  is  organized  into  two  logical  parts.  The  first  part  summarizes  the  needs,  re¬ 
quirements,  state  of  the  art  voids  and  IISEE  plan.  The  second  part  provides  details  of 
the  technical  research  and  assessment  activities.  The  following  describes  the  contents  of 
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each  chapter.  The  contents  of  the  10  appendices  are  described  as  referenced  in  the  various 
chapters. 

The  remainder  of  Chapter  1  is  focused  on  EDS  information  integration  philosophy  and 
the  concept  of  an  integrated  information  system  evolution  environment  (IISEE).  The  IDS 
overview  provides  the  technical  context  of  the  methodologies  and  tools  we  are  considering. 
The  IISEE  overview  provides  an  introduction  to  some  of  the  key  definitions  and  concepts 
which  directed  towards  this  work.  The  IISEE  overview  is  meant  to  provide  a  high  level 
picture  of  what  the  coalition  perceives  as  the  “end  game”  of  the  plan  presented  in  Section 
3.5  of  this  report. 

Chapter  2  provides  a  summarization  of  key  results  of  the  analysis  efforts  in  this  project. 
The  first  section  provides  an  overview  of  the  problems  which  organizations  face  in  attempts 
to  achieve  information  integration  of  engineering  and  manufacturing  information  systems. 
This  section  also  summarizes  the  problems  with  existing  methods,  and  automated  tools 
as  perceived  by  systems  engineers  in  various  organizations.  Finally  this  section  presents 
a  summary  of  organizational  needs  relative  to  methodologies,  frameworks,  and  automated 
tools  and  environments  for: 

1.  Strategic  Information  Integration  Planning 

2.  Tactical  Planning 

3.  Design 

4.  Construction 

5.  Implementation 

6.  Evolution  /  Maintenance 

Section  2.2  summarizes  the  efforts  of  the  project  team  to  construct  a  model  of  the  process 
of  integrated  information  system  evolution.  The  project  team  recognizes  the  need  to  produce 
an  activity  model  to  structure  the  process  of  identification  of  existing  methods,  automated 
tools,  and  to  provide  a  basis  for  the  structuring  of  the  technology  voids.  Section  2.3  sum¬ 
marizes  the  results  of  the  state-of-the-art  assessment  of  methodologies  and  automated  tools 
which  are  available  to  support  the  activities  of  the  information  system  evolution  models  dis¬ 
cussed  in  Section  2.2.  Finally,  Section  2.4  provides  a  description  of  the  requirements  for  an 
IISEE  based  on  company  needs,  the  development  process  definition,  and  the  state-of-the-art 
review  results.  Chapter  2  provides  the  basis  for  the  plan  proposed  in  Chapter  3  of  this  report. 

Chapter  3  provides  a  plan  for  the  development  of  the  enabling  technologies  which  will 
(with  the  existing  methodologies  and  automated  tools)  provide  an  IISEE  for  organizations 
to  implement  and  maintain  information  integrated  engineering  and  manufacturing  systems. 
Section  3.1  provides  a  justification  for  the  the  component  and  framework  developments  in 
the  context  of  the  IDS  Program  goals  and  objectives.  Section  3.2  identifies  the  requirements 
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for  framework  and  component  methodology  developments.  Section  3.3  identifies  the  require¬ 
ments  for  automated  tools  and  environments  to  support  the  application  of  the  framework 
and  component  methodologies.  Section  3.4  identifies  the  requirements  for  technology  trans¬ 
fer  efforts  needed  to  support  the  dissemination  of  the  results  of  an  IISEE  program.  Finally, 
Section  3.5  provides  a  series  of  project  descriptions,  with  time  and  resource  estimates  for  the 
development  of  the  enabling  technologies  identified  in  Sections  3.2  through  3.4. 

Chapters  4  and  5  present  the  results  of  some  investigative  research  which  was  performed 
as  a  part  of  this  effort.  One  of  the  major  industry  needs  i6  for  integration  of  the  component 
methodologies  within  a  unified  framework.  A  major  stumbling  block  to  the  accomplishment 
of  this  integration  is  the  lack  of  a  formal  basis  for  any  of  the  existing  techniques.  Chapter  4 
presents  the  results  of  an  effort  to  formally  define  the  syntax  and  semantics  of  a  number  of 
existing  systems  analysis  and  engineering  methods  in  widespread  use  today.  The  rationale 
behind  this  formalization  effort  is  to: 

1.  Identify  the  informal  intuitions  that  motivate  the  existing  methods. 

2.  Provide  a  technical  basis  for  the  integration  of  existing  methods. 

3.  Provide  an  objective  basis  for  the  comparison  of  methods  to  support  usage  planning. 

4.  Provide  a  technical  basis  and  an  engineering  technique  for  the  design  of  new  methods. 

5.  Provide  accurate  specifications  for  the  design  of  automated  tools. 

Central  to  the  feasibility  of  establishing  automated  support  for  the  integration,  manage¬ 
ment  and  life  cycle  control  of  the  data  associated  with  a  system  development  process  is  the 
capability  to  have  a  representation  scheme  for  this  information  which  is  logically  a  superset 
of  the  individual  methodologies.  Section  4.4  describes  the  concepts,  rationale,  and  prelimi¬ 
nary  requirements  for  such  a  representation  scheme.  This  will  be  refered  to  as  the  “Neutral 
Information  Representation  Scheme”  (NIRS). 

Chapter  5  summarizes  an  investigation  conducted  into  the  use  of  natual  language  pro¬ 
cessing  techniques  for  the  acquisition  of  system  description  information,  model  validation 
support,  and  translation  between  methodology  types.  This  section  also  describes  exploratory 
work  in  the  use  of  knowledge  engineering  languages,  tools,  and  environments  as  the  basis  for 
construction  of  the  IISEE  automated  tools,  and  as  a  basis  for  improvements  to  the  funda¬ 
mental  IDS  technology  itself. 

The  ten  appendices  contain  detailed  information  resulting  from  the  analysis  activities 
associated  with  this  project. 

1.5  EDS  Technology  Concepts  and  Implications 

The  Integrated  Design  Support  System  Program  is  focused  on  the  capture,  management, 
and  communication  of  product  technical  data  from  its  initial  creation  in  design,  through 
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realization  in  manufacture,  to  logistics  operations  (see  Figure  1.1).  The  extent  of  the  chal¬ 
lenge  facing  the  IDS  in  the  defense  system  arena  spans  hundreds  of  contractors,  world  wide 
development  and  operation,  war  and  peace  situations,  and  a  product  life  cycle  which  can 
easily  span  twenty  years.  Obviously  the  information  technology  across  this  extent  of  orga¬ 
nization,  space,  situation,  and  time  will  vary  significantly.  One  of  the  major  targets  of  IDS 
is  to  isolate  the  product  data  from  the  changes  in  the  information  processing  technology  so 
that  as  new  technology  emerges  it  can  be  quickly  and  reliably  inserted  into  the  process  (see 
Figure  1.2).  The  major  data  control  issues  which  the  IDS  Program  addresses  are  listed  in 
Figure  1.3.  The  immensity  of  this  task  is  somewhat  mitigated  by  the  fact  that  only  critical 
product  data  needs  to  be  controlled  (see  Figure  1.4). 

The  approach  taken  in  the  IDS  development  is  an  implementation  of  the  ISO/ ANSI 
three  schema  architecture  concept  utilizing  commercially  available  software.  Under  this  ap¬ 
proach,  enterprise  information  control  is  accomplished  via  the  establishment  of  a  “conceptual 
schema”  and  an  “executive  control  system.”  The  conceptual  schema  contains  a  definition  of 
the  enterprise  information  management  and  control  rules  (see  Figure  1.5).  The  logic  behind 
the  IDS  concept  i6  that  the  executive  control  system  validates  each  transaction  against  these 
rules.  This  removes  (in  concept)  constraint  checking  from  the  AP’s.  It  also  centralizes  and 
provides  the  basis  for  the  control  of  critical  data  in  the  organization. 

However,  this  requires  definition  of  an  enterprise  conceptual  schema.2  It  also  requires 
changing  the  way  applications  are  designed  and  built.  One  of  the  primary  changes  required 
is  the  enforcement  of  more  uniformity  and  control  on  the  system  development  methodologies 
used  within  the  organization.  However,  before  such  uniformity  can  be  demanded  a  workable 
set  of  component  methodologies  and  development  frameworks  must  be  engineered.  This  is 
one  of  the  driving  factors  behind  this  effort.  The  IDS  has  been  prototyped  and  demonstrated. 
From  this  experience  and  the  experience  of  other  programs  (e.g.  the  AFWAL/MLTC  IISS) 
it  is  known  that  there  are  key  methods  missing.  It  is  also  known  that  the  complete  set  of 
methods  needed  would  be  too  expensive  to  implement  in  a  manual  fashion.  An  automated  set 
of  component  tools  is  needed  to  support  each  of  the  methods,  and  an  integration  framework 
to  allow  movement  of  data  between  tools  is  also  required.  Finally,  a  life  cycle  data  control 
mechanism  is  needed  to  manage  the  evolution  of  that  process.  These  needs  and  others  will 
be  described  in  later  sections  of  this  report. 

Prior  to  attempting  any  description  of  the  IISEE  concepts,  it  is  important  to  under¬ 
stand  the  context  within  which  it  is  anticipated  that  an  IDS  shell  will  likely  be  implemented. 
While  there  are  similarities,  there  appear  to  be  some  major  differences  between  the  planning, 
design,  development,  implementation,  and  maintenance  of  systems  for  managing  and  con¬ 
trolling  engineering/manufacturing  technical  data  (at  which  the  IDS  is  primarily  directed) 


2An  enterprise  conceptual  schema  can  be  roughly  equated  to  a  definition  of  the  common  data  in  a  company 
which  is  used  to  govern  the  access,  update,  and  use  of  that  critical  data.  Such  a  definition  is  complex  and 


costly  to  develop  using  current  methods  and  tools.  However  the  potential  payback  in  terms  of  reduced  product 
cycle  time  and  improved  organisational  responsiveness  has  been  shown  to  far  outshadow  the  costs 
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Figure  1.1:  IDS  Program  Approach 
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Figure  1.2:  Technology  Insertion  Under  IDS 
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and  tome  other  forms  of  business  oriented  data.  These  differences  are  associated  with  the 
complexity  of  the  data,  user  interfaces,  and  techniques/tools  that  are  used  to  evolve  the  data. 
Technical  data  has  a  distinct  life  cycle  that  evolves  over  time  with  many  inter-dependencies 
that  must  be  tracked  and  controlled  and  which  correlate  to  an  emerging  product  definition. 
For  example,  technical  data  starts  as  a  definition  of  an  initial  concept  that  identifies  the 
target  product’s  basic  mission,  such  as  performance,  cost  and  weight  requirements.  Pre¬ 
liminary  design  data  describes  the  basic  product  structure  which  can  then  be  simulated  to 
determine  how  well  the  preliminary  design  can  achieve  the  target  requirements.  Project 
Management  is  concerned  with  the  evolution  status  of  the  product  design  at  key  decision 
points  throughout  its  entire  life  cycle.  Project  Management  approves  each  step  in  the  product 
design /development  process.  When  new  designs  are  completed,  changed,  and/or  released, 
appropriate  organizational  groups  must  be  notified.  Since  there  is  so  much  technical  data 
associated  with  complex  mechanical  products  such  as  aircraft,  space  stations,  ships,  etc.,  it 
is  essential  to  develop  systems  that  are  capable  of  managing  and  controlling  the  evolution 
and  maintenance  of  this  type  of  data.  The  following  paragraphs  further  describe  some  of 
these  complexities: 

•  Data  Life  Cycles  -  technical  data  evolves  through  life  cycle  states.  Different  technical 
data  types  are  dependent  upon  each  other  and  must  satisfy  certain  constraints  before 
their  state  changes  are  approved. 

•  Configuration  Management  -  products  have  a  specific  structure  (configuration)  that 
must  be  managed  throughout  the  product  life  cycle.  Technical  Data  describes  the 
various  components  that  comprise  the  product  structure.  Changes  to  the  product 
structure  must  be  managed  to  insure  that  the  proper  component  designs  are  released 
for  production. 

•  Status  Accounting  -  since  technical  data  is  critical  to  the  evolution  of  the  product,  its 
evolution  status  (state)  is  important  to  the  project /technical  managers  and  engineers 
expecting  to  use  the  data  as  it  evolves. 

•  Complex  Applications  -  technical  data  (geometries,  simulation,  test)  is  produced  by 
applications  that  are  graphically  oriented;  i.e.,  they  input/output  2  dimension,  3  di¬ 
mension,  solid  representations,  scatter  grams,  line  curve  charts,  etc.  These  applications 
typically  maintain  their  own  data  structures  and  normally  do  not  share  data  because 
it  is  in  different  formats. 

Hardware/Software  technology  is  continuing  to  evolve.  Powerful  single  user  engineering 
workstations  are  becoming  economical  to  obtain  and  use.  This  trend  establishes  a  need  to 
deal  with  distributed  data  that  is  being  developed  by  heterogeneous  applications  that  may 
or  may  not  be  communicating  with  a  central  system.  Thus,  the  IDS  system  development 
process  must  also  deal  with  the  distributed  nature  of  the  data  as  well  as  its  complexities,  life 
cycle  control  characteristics,  and  relationship  to  other  kinds  of  business  data. 
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These  are  just  a  few  of  the  complex  issues  that  must  be  accommodated  by  an  IDS  shell. 
A  facility  which  adequately  addresses  these  issues  is  likely  to  address  the  data  management 
issues  associated  with  other,  less  complex  forms  of  business  data  as  well. 


1.6  Terminology 

The  objective  of  this  section  is  to  provide  a  definition  of  the  terminology  which  will  be  used 
in  the  remainder  of  this  report,  and  to  provide  a  high  level  view  of  the  IISEE  concept.  A 
more  detailed  description  of  the  IISEE  concept  is  provided  in  Section  2.4  of  this  report. 

As  with  any  emerging  discipline,  systems  engineering  is  still  in  the  process  of  resolving 
the  terminology  associated  with  the  concepts  inherent  in  its  theory  and  practice.  This  lack 
of  terminology  standardization  is  a  major  stumbling  block  for  advancement  of  the  state  of 
the  art  of  this  discipline.  For  the  purpose  of  communication  among  the  coalition  members, 
we  adopt  the  following  definitions  for  the  concepts  presented  in  Figure  1.6. 

1.  Framework  -  A  collection  of  methodologies  tied  together  by  a  development  procedure 
to  support  the  development  of  a  particular  type  of  system  in  a  specific  type  of  or¬ 
ganizational  environment.  A  framework  provides  the  overall  integration  method  for 
an  application  in  an  environment.  Because  of  this  role  it  will  be  refered  to  as  an 
Integrating  Framework  in  the  plan  section  of  this  report. 

2.  Methodology  -  A  collection  of  methods  with  similar  semantics  and  application  areas 
(e.g.  an  Information  Modeling  Methodology  would  include  ENAL1M,  IDEF1,  EER, 
IDEF1X,  etc.). 

3.  Development  Procedure  -  A  collection  of  decisions  and  actions  organized  into  steps  and 
phases  which  describe  the  activities  required  to  develop  or  evolve  a  particular  type  of 
system.  The  development  procedure  would  call  for  the  use  of  many  methods  as  well  as 
define  the  decisions  to  be  made  with  the  results  of  application  of  those  methods.  Where 
possible  the  development  procedure  will  call  for  the  use  of  a  methodology  indicating 
that  any  method  within  that  class  with  certain  characteristics  would  be  acceptable. 

4.  Method  -  A  defined  set  of  concepts,  along  with  a  discipline,  which  would  guide  the  ap¬ 
plication  of  concepts  for  a  particular  use  in  support  of  a  particular  system  development 
life  cycle  activity  (e.g.  the  IDEFl  method  or  the  IDEFO  method). 

5.  Definition  -  The  collection  of  concepts  and  the  theory  of  how  the  concepts  work  together 
to  map  onto  a  particular  aspect  of  reality.  The  definition  component  of  a  method 
essentially  consists  of  both  the  formal  and  informal  description  of  the  method. 

6.  Concepts  -  The  motivating  intuitions  or  basic  modeling  elements  of  a  method  (e.g. 
entity  classes,  relation  classes,  and  attribute  classes  in  IDEFl). 
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7.  Theory  -  The  logic  which  describes  how  the  basic  concepts  of  a  method  work  together 
to  represent  a  particular  view  of  reality  (e.g.  activity,  information,  process  etc.)  to 
support  a  specific  system  development  activity  (e.g.  planning,  analysis,  design  etc.). 

8.  Discipline  -  The  description  of  how  to  acquire  information  about  a  system  and  orga¬ 
nize/display  that  information  using  a  particular  method.  The  discipline  component 
of  a  method  contains  the  practical  application  instructions  (i.e.  How  to  do  it)  for  the 
method. 

9.  Syntax  -  The  description  of  the  symbols  and  presentation  rules  of  a  method  (e.g.  boxes 
and  arrows  and  decomposition  rules  in  IDEFO  function  modeling). 

10.  Procedures  -  The  description  of  the  activities  which  a  modeler  must  go  through  in 
order  to  collect,  organize,  analyze  and  validate  information  about  a  system  in  order  to 
build  a  model  using  a  particular  method.  The  procedure  component  normally  consists 
of  procedure  descriptions,  data  collection  /  analysis  forms,  and  library  organization 
guidelines. 

11.  Use  -  A  description  of  the  activities  which  a  system  developer  performs  to  analyze  a 
completed  model  and  extract  information  necessary  to  perform  the  next  step  in  the 
system  development  process. 

12.  Environment  -  Refers  to  an  automated  system  provided  for  the  support  and  integration 
of  the  overall  life  cycle  activities  associated  with  the  planning,  definition,  engineering, 
design,  implementation,  and  evolution  of  an  information  system.  The  environment 
is  considered  to  include  the  data  management  utilities,  interface  utilities  and  control 
mechanisms  required  to  support  the  use  of  the  tools  and  computer  languages  in  an 
integrated  manner.  The  environment  can  be  thought  of  as  the  automated  version  of 
an  integration  framework  for  the  support  of  the  system  development  team. 

13.  Tool  -  In  the  context  of  this  report,  this  refers  to  any  automated  mechanism  or  imple¬ 
mentation  of  a  modeling  cr  programming  concept  which  is  too  complex  or  specialized 
to  be  considered  as  a  part  cf  a  base  language. 

14.  Computer  Language  -  In  the  context  of  this  report,  this  refers  to  the  procedural,  func¬ 
tional,  logic,  object  oriented,  or  descriptive  languages  which  are  used  to  construct  an 
IDS  like  information  integration  system  or  the  applications  within  such  an  environ¬ 
ment.  The  construction  and  use  of  an  IDS  based  system  requires  many  special  purpose 
languages  (e.g.  schema  definition  languages,  user  interface  definition  languages  etc.) 
as  well  as  traditional  programming  languages  (e.g.  COBOL,  FORTRAN,  C,  LISP 
etc.)  all  of  which  must  be  supported  by  an  automated  system  development  support 
environment. 
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Figure  1.6:  Key  Terminology  Relationships 
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1.6.1  IISEE  Overview 

If  we  invoke  a  product  view  of  IISEE  and  look  towards  the  future  (after  the  plan  outlined  in 
Section  3.5  has  been  put  into  place),  we  can  imagine  a  systems  developer  in  an  organization 
placing  an  order  for  an  IISEE.  What  might  arrive  would  be  a  diskette  which  would  contain  a 
small  expert  system  which  would  help  him  to  relate  his  current  situation  to  the  “standard” 
frameworks  provided  by  the  IISEE  product  line.  Once  the  user  has  adequately  responded 
to  the  questions  of  the  program,  a  configuration  of  product  and  software  would  be  produced 
which  could  be  ordered  from  DTIC.  Presuming  the  user  places  such  an  order,  he  would 
eventually  receive  a  large  carton  whose  contents  are  illustrated  in  Figure  1.7. 

The  “Guidebook”  item  in  the  carton  would  contain  an  overview  of  the  philosophy,  as¬ 
sumptions,  and  structure  of  the  approach  to  systems  development  embodied  in  the  IISEE. 
This  document  also  contains  a  description  of  a  method  for  analyzing  specific  system  devel¬ 
opment  needs  so  that  he  can  accurately  use  the  “Guide”  expert  system.  The  “Guide”  would 
lead  the  recipient  through  a  series  of  questions  which  would  result  in  a  recommended  selec¬ 
tion  of  one  of  the  smaller  boxes  in  the  carton.  The  smaller  boxes  each  contain  a  framework, 
complete  with  a  development  procedure  and  a  collection  of  methodologies.  ( Obviously  in 
some  cases  the  specific  method  referred  to  by  a  step  in  the  development  procedure  may  not  be 
included  since  it  is  a  commercial  product.) 

In  the  bottom  of  the  carton  is  included  a  set  of  tapes  and  another  diskette.  These  tapes 
contain  the  IISEE  system/software  development  factory.  That  is,  the  system  development 
environment  (SDE),  component  tools,  and  languages  required  to  provide  automated  support 
for  the  execution  of  a  framework.  The  setup  diskette  contains  another  expert  system  which 
identifies  what  hardware,  commercial  software,  and  people  skills  are  required  to  setup  and 
operate  the  factory.  It  also  contains  the  instructions  for  configuring  the  factory  for  the 
particular  framework  chosen. 
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When  most  of  us  think  of  an  engineering/manufacturing  project,  three  issues  come  to  mind: 
planning,  management,  and  control.  Planning  is  the  process  of  preparing  for  the  commit¬ 
ment  of  project  resources  in  the  most  effective  manner.  Management  is  the  process  through 
which  project  goals  and/or  objectives  axe  achieved.  Planning  involves  the  coordination  of 
group  activities,  wherein  management  requires  plans,  organizations,  staffing,  direction  and 
imposition  of  controls  to  achieve  an  objective  with  constraints  placed  on  time,  cost,  and 
performance.  Control  is  the  process  of  making  events  conform  to  a  schedule  by  coordinating 
the  actions  of  all  organizations  according  to  the  plan  established  for  achieving  the  objective. 

For  engineering  and  manufacturing  to  operate  cost  effectively,  there  must  be  management 
and  control  of  technical  product  data.  This  has  become  an  increasingly  critical  aspect  of 
Computer  Aided  Design /Computer  Aided  Manufacturing  (CAD/CAM)  activities  within  en¬ 
gineering  and  manufacturing  environments.  When  engineering  and  manufacturing  processes 
are  conducted,  a  variety  of  data  management  and  control  problems  may  be  encountered  (i.e., 
the  problems  that  occur  when  controlling  engineering  changes,  accessing  data,  tracking  data, 
and  managing  the  product  configuration,  etc.).  Currently,  systems  that  manage  and  con¬ 
trol  technical  product  data  are  non-integrated,  thus  causing  engineering  and  manufacturing 
project  planning,  management  and  control  as  well  as  CAD/CAM  to  be  decentralized,  time 
consuming,  and  costly  processes.  The  IDS  technology  provides  a  mechanism  for  achieving 
the  needed  integration  of  this  technical  data.  The  primary  issue  before  companies  today  is 
how  to  implement  integration  programs  which  can  take  advantage  of  this  technology. 


2.1  Existing  Methods  and  Needs 

This  section  addresses  issues,  problems  and  voids  associated  with  the  use  of  existing  (appli¬ 
cation  engineering  based)  methods  for  developing  and  implementing  integrated  information 
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systems.  It  also  discusses  generic  company  needs  for  integrating  frameworks,  component 
methods,  automated  tools,  and  technology  transfer  mechanisms. 

2.1.1  Issues 

Very  little  experience  is  available  when  it  comes  to  conducting  the  level  of  analysis  that  is 
required  to  establish  an  overall  enterprise  strategic  or  tactical  plan  for  the  development  and 
implementation  of  integrated  information  systems  within  engineering/manufacturing  envi¬ 
ronments.  The  function,  information  and  dynamics  modeling  methodologies  (i.e.,  IDEF0,1,2) 
being  utilized  today  were  designed  to  be  used  as  techniques  that  document  requirements  for 
establishing  integrated  information  systems.  These  methods  have  been  used  on  several  Air 
Force  and  commercial  programs  with  varying  degrees  of  success. 

Major  corporations  that  conduct  business  with  the  DoD  in  the  future  will  be  required 
to  develop  integrated  information  systems  that  can  communicate  over  distributed  networks. 
In  order  to  accomplish  this,  these  companies  will  have  to  develop  strategic,  tactical  and 
operational  plans  for  implementing  these  types  of  systems.  Once  the  plans  are  approved,  they 
will  be  initiated  as  programs  with  many  tightly  related  projects  to  either  develop  or  obtain  the 
required  information  or  system  integration  technology,  and  then  to  implement  applications 
within  it.  This  is  a  major  undertaking  that  requires  a  comprehensive  integrated  information 
system  evolution  environment  that  can  be  used  throughout  the  design,  development  and 
implementation  phases  of  the  project. 

Several  issues  relating  to  the  “AS  IS”  information  environment  in  engineering  /  manu¬ 
facturing  industries  have  been  identified  that  pertain  to  the  design,  development  and  imple¬ 
mentation  of  integrated  information  systems.  Examination  of  these  issues  helps  to  expose 
the  need  for  effective  methods  that  support  each  phase  of  the  system  evolution  life  cycle. 
These  issues  are  as  follows: 

•  Paper  Volume  -  most  major  engineering/manufacturing  corporations  maintain  large 
volumes  of  technical  data  (e.g.,  drawings,  specifications,  technical  reports,  etc.)  that 
exist  on  paper.  Many  of  these  companies  are  in  the  process  of  converting  these  data  to 
electronic  form  using  a  variety  of  non-integrated  applications  that  operate  on  computer 
systems  such  as  PCs  (personal  computers),  mini  computers  and  large  host  computers. 
There  is  growing  concern  about  the  global  management  and  control  of  this  data. 

•  Non-integrated  Systems  -  many  systems  exist  within  engineering  /  manufacturing  com¬ 
panies  that  were  developed  independent  of  one  another.  In  most  cases,  these  systems 
utilize  different  operating  systems  and  data  base  management  systems.  This  means 
that  they  do  not  share  the  data  that  they  utilize  and  more  often  than  not  will  dupli¬ 
cate  the  data  causing  consistency  problems.  Existing  systems  must  be  factored  into 
any  integrated  information  system  strategy. 
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•  Cultural  Impact  -  for  the  most  part,  company  employees  have  not  been  mentally  pre¬ 
pared  for  the  technological  evolution  of  integrated  information  systems.  In  most  cases, 
corporate  management  and  individual  department  managers  within  the  enterprise  do 
not  understand  the  importance  of  information  or  system  integration.  Even  in  cases 
where  integrated  information  systems  are  beginning  to  be  implemented,  end  users  are 
reluctant  to  support  them.  This  reluctance  can  be  traced  to  at  least  three  sources: 

1.  Apparent  loss  of  control  by  the  individual  organization  of  common  data. 

2.  The  additional  time  and  effort  of  development  of  integrated  applications. 

3.  The  loss  of  local  flexibility  to  change  policies  and  rules  governing  the  data. 

4.  Potential  degredation  of  response  in  individual  applications  due  to  access  of  com¬ 
mon  data. 

•  Evolving  Technology  -  in  recent  years  computer  technology  has  proliferated.  Much 
of  the  application  functionality  that  was  once  located  on  host  systems  is  now  being 
employed  at  the  workstation  level.  Similarly,  data  that  was  once  stored  on  mechanical 
disk  devices  is  now  being  archived  on  large  volume  optical  storage  devices.  In  addition 
the  emergence  of  knowledge  based  systems  in  manufacturing  and  engineering  appli¬ 
cations  is  introducing  a  new  type  of  common  data  which  must  be  managed.  These 
phenomena  further  complicate  the  information  integration  issue.  Methods  need  to  be 
developed  that  can  effectively  model  distributed  data  and  knowledge  as  well  as  the  the 
network  structures  it  will  be  transmitted  over. 

•  Knowledge  Attrition  -  in  recent  years  there  has  been  a  gradual  disappearance  of  engi¬ 
neering/manufacturing  knowledge.  Engineering  and  manufacturing  expertise  that  has 
evolved  over  the  last  thirty  years  is  beginning  to  erode  within  many  companies  due  to 
the  retirement  of  those  individuals  that  have  many  years  of  experience  in  design  and 
production  processes.  In  the  past,  a  design  engineer  may  have  derived  his  experience 
from  earlier  manufacturing  experience.  This  trend  towards  erosion,  in  conjunction 
with  rapid  technological  advances,  is  causing  major  problems  within  industry.  Once 
knowledge  disappears,  it  is  very  difficult  to  regain  it  through  training  and  education. 
Engineering  and  manufacturing  expertise  needs  to  be  captured  in  a  corporate  knowl¬ 
edge  base  that  can  evolve  over  time  and  be  accessible  to  a  new  breed  of  engineers  that 
are  emerging  from  our  educational  institutions. 

•  Global  Product  Data  Knowledge  -  since  information  systems  are  not  currently  inte¬ 
grated,  it  is  difficult  if  not  impossible  to  obtain  the  status  of  evolving  technical  product 
data.  Management  must  usually  wait  long  periods  of  time  to  obtain  status  information 
pertaining  to  critical  technical  data.  This  is  due  to  the  lack  of  a  global  configuration 
management  and  control  capability  that  is  capable  of  tracking  and  reporting  the  life 
cycle  states  of  evolving  technical  data  related  to  the  product. 


R5v 

Ew 


rSj! 

1 


CKS- 


CHAPTER  2.  INFORMATION  ENGINEERING  NEEDS,  PROCESS,  AND  SO  A  28 

•  Data  Longevity  -  the  life  expectancy  of  military  weapons  systems  spans  20  years  or 
more.  These  weapons  systems  are  subject  to  change  or  modification  rather  than  new 
design  and  development.  The  technical  data  that  is  associated  with  these  weapons 
systems  must  remain  accessible  throughout  the  entire  weapons  system  life  span  so 
as  to  facilitate  quick  and  cost  effective  design  modifications  or  repairs  that  may  be 
required. 

2.1.2  Integrated  Information  Management  and  Control  Definition 
Needs 

When  determining  integrated  information  system  requirements  it  is  important  to  realize  that 
each  enterprise  is  different  and  each  has  its  own  set  of  management  policies  and  operational 
procedures.  Changing  these  policies  and  procedures  in  order  to  satisfy  the  requirements  of 
a  “general  purpose”  system  would  be  a  disastrous  step.  Also  as  the  needs  for  an  IDS  like 
information  integration  mechanism  become  more  wide  spread  the  number  of  “vendors”  who 
want  to  fill  those  needs  will  increase.  Without  a  standard  definition  of  what  functionality 
must  be  delivered  by  such  an  information  integration  mechanism  company  management  will 
be  unable  to  make  informed  decisions  between  suppliers.  What  is  needed  is  an  integrated 
information  system  definition  (a  standard  IDS  description)  that  can  be  customized  to  support 
data  management  and  control  needs  of  the  enterprise.  A  set  of  typical  concerns  that  a  system 
such  as  this  would  have  to  address  are  as  follows: 

•  Engineering  Change  Control  -  Authorized  engineering  changes  made  during  product 
design  processes  are  costly  in  terms  of  the  time  and  money  that  is  expended  to  actually 
make  the  change.  For  instance,  changing  a  part  design  that  is  stored  in  one  file  may 
directly  affect  many  related  part  designs  that  are  stored  in  other  files.  Each  time  a 
part  design  is  changed,  the  changed  part  design  and  the  related  part  designs  that  are 
affected  by  the  change,  must  be  reviewed  and  approved  by  design,  analysis  and  test 
engineers  assigned  to  the  project  management  team.  It  is  essential  that  part  designs 
changed  and/or  affected  by  a  change  be  properly  controlled  so  that  updates,  reviews 
and  approvals  can  take  place  in  a  logical  and  efficient  manner.  Notification  and  approval 
messages  must  be  generated  when  changes  have  occurred  to  the  product  data. 

•  Data  Access  -  Early  in  the  design  process,  engineers  should  be  able  to  easily  create, 
access,  and  change  part  design  files.  In  the  later  stages  of  the  design  process,  part 
design  files  should  be  protected  from  unauthorized  access.  This  means  that  engineers 
working  on  the  project  should  not  be  able  to  access  and  change  the  part  design  files  that 
have  been  reviewed,  approved  and  released  for  analysis,  prototype  and  test  activities. 
If  unauthorized  design  changes  occur  due  to  a  lack  of  access  control,  the  time,  money 
and  effort  expended  to  rectify  the  problems  that  are  caused  by  design  errors  can  be 


enormous. 
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•  Data  Tracking  -  Part  design  data  must  be  tracked  so  that  it  can  quickly  be  located  and 
retrieved  for  evaluation  when  design  problems  are  uncovered  during  analysis  and  test 
activities.  On  a  large  project,  this  becomes  a  major  problem  because  part  design  data 
proliferates  when  the  product  structure  is  complex,  i.e.,  composed  of  many  parts.  To 
compound  the  problem,  the  analysis  and  test  runs  create  additional  volumes  of  data 
that  also  must  be  tracked.  When  design,  analysis  and  test  data  can  not  be  located, 
major  project  delays  occur  and  design  errors  go  undetected. 

•  Product  Configuration  Management  -  a  product  is  made  up  of  many  parts,  which  in 
themselves  may  be  made  up  of  many  component  parts  and/or  assemblies.  The  rela¬ 
tionship  that  exists  between  a  part  and  its  component  parts  is  called  the  product  con¬ 
figuration  (structure).  It  has  become  increasingly  important  to  maintain  the  integrity 
of  the  product  configuration  throughout  its  life  cycle.  Being  able  to  identify  which 
component  parts  are  associated  with  a  particular  sub-assembly,  which  sub-assemblies 
make  up  an  assembly,  and  what  life  cycle  design  process  state  of  the  each  component 
part  exhibits,  provides  the  project  management  team  with  the  necessary  information 
to  effectively  evaluate  the  evolving  product  design. 

A  set  of  more  specific  requirements  of  an  integrated  information  system  definition  are  as 
follows: 

•  Manage  data  at  the  file  and/or  database  level.  The  system  must  be  able  to  manage  var¬ 
ious  types  of  product  data  objects:  CAE  geometry,  CAD  drawings,  analytical  models, 
test  data,  specifications,  etc. 

•  Manage  data  from  multiple  computing  environments.  Most  engineering  organizations 
utilize  more  than  one  computer  to  perform  various  functions.  The  system  must  be  able 

,  to  locate  a  data  object  within  the  network  of  computers  and  make  it  available  to  the 
user. 

•  Manage  data  from  multiple  organizations.  The  system  must  track  the  location  of 
distributed  data  that  is  outside  its  own  environment.  Furthermore,  it  must  be  able  to 
notify  authorized  users  when  data  has  changed  and/or  is  affected  by  a  change. 

•  Enable  the  definition  of  multiple  relationships  between  data  objects.  Engineering  data 
objects  (in  this  case  parts)  are  interrelated  and  form  a  product  structure.  Geometry, 
analysis,  and  test  data  are  related  to  parts  within  the  product  structure.  A  change  to 
any  one  of  the  data  objects  may  affect  the  others;  thus,  it  is  important  that  the  system 
maintains  relationships  between  data  objects. 

•  Control  data  object  access.  The  system  should  limit  user  access  to  product  data 
objects.  For  example,  a  design  engineer  should  have  “read/write”  access  to  his  own 
product  data  files  when  they  are  in  the  “pre-release”  design  phase.  This  same  design 
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engineer  should  have  “read  only”  access  to  another  design  engineers  product  data  files. 
Once  the  product  data  files  are  in  a  “released”  state,  users  should  only  be  able  to 
obtain  copies  of  the  released  files. 

•  Control  data  release.  The  system  should  track  the  life  cycle  status  of  all  product  data 
files.  In  order  to  accomplish  this,  each  file  must  be  assigned  a  set  of  life  cycle  states 
through  which  it  will  evolve.  The  states  should  be  defined  by  the  project  management 
team  according  to  existing  policies  and  operating  procedures. 

•  Provide  query  commands  across  the  network.  The  system  should  provide  the  user  with 
the  capability  to  query  any  data  that  exists  within  the  system.  For  example,  one  might 
ask  for  a  list  of  all  the  CAD  drawings  that  are  in  the  system,  or  all  the  analysis  runs 
that  were  performed  on  a  particular  part  geometry. 

•  Generate  messages.  The  system  should  generate  both  informative  and  action  messages 
that  alert  project  team  members  when  the  status  of  a  product  data  file  has  changed 
or  when  review/approval  is  required.  The  system  should  should  allow  project  team 
members  to  interactively  respond  to  the  messages. 

•  Control  formats.  The  system  should  enable  project  team  members  to  design  menus, 
data  input  screens,  and  printed  report  forms  which  are  similar  to  those  forms  already 
in  use.  By  emulating  existing  paper  forms,  reports  and  procedures,  the  time  it  takes 
to  teach  system  functionality  can  be  reduced  and  political  barriers  can  be  avoided. 

2.1.3  Methodology  Scope  Expansion  Needs 

The  ICAM  System  Development  Methodology  Project  (December  1985)  did  not  address  the 
Administer  Business  Information  Strategy ,  Administer  Program  or  Manage  Project  activities. 
These  activities  are  an  important  aspect  of  the  design,  development  and  implementation  of 
integrated  information  systems.  They  represent  the  strategic  and  tactical  decision  making 
process.  Companies  need  a  methodology  when  entering  a  new  business  venture  that  will 
help  assess  the  affect  on  the  entire  enterprise  information  strategy.  The  company  should 
develop  an  information  strategy  consistent  with  thier  business  strategy  by  first  evaluating 
the  strategic  concepts,  followed  by  a  definition  and  prioritization  of  strategic  objectives.  The 
information  strategy  should  be  developed  by  first  planning,  then  authorizing,  then  controlling 
strategic  projects.  A  strategic  project  may  be  the  design,  development,  and  implementation 
of  an  integrated  information  system.  If  so,  companies  need  a  methodology  of  planning  and 
managing  the  evolution  of  such  a  system.  This  is  a  complex  undertaking  that  involves  the 
development  of  an  evolution  strategy.  The  evolution  strategy  should  take  into  account  the 
impact  that  a  system  such  as  this  will  have  on  the  business  strategy  as  well  as  the  business 
operations.  The  evolution  strategy  should  also  include  a  comprehensive  tactical  plan  that 
addresses  development,  management,  service,  and  resource  planning. 


CHAPTER  2.  INFORMATION  ENGINEERING  NEEDS,  PROCESS,  AND  SOA 


31 


2.1.4  framework  Needs 

Engineering/manufacturing  companies  generally  tend  to  have  their  own  unique  way  of  con¬ 
ducting  strategic,  tactical  and  operational  planning  for  the  implementation  of  information 
systems.  Now  that  these  companies  are  becoming  more  aware  of  the  importance  of  inte¬ 
grated  information  system  technology,  there  is  a  vital  need  for  a  cohesive  framework  that 
guides  management  through  the  various  levels  of  strategic,  tactical  and  operational  planning 
that  is  required  for  effective  analysis,  design,  development,  and  implementation  of  integrated 
information  systems.  Integrated  information  systems  technology  is  a  new  technology  that 
involves  the  entire  enterprise  including  upper  level  management,  engineering,  and  manufac¬ 
turing.  Traditional  methodologies  are  not  robust  enough  and  are  primarily  oriented  towards 
stand  alone  application  software  development  projects  rather  than  enterprise  wide  informa¬ 
tion  system  integration.  In  short,  the  framework  required  to  conduct  the  depth  and  breadth 
of  effort  required  for  an  information  integration  program  within  a  company  are  not  currently 
in  place. 

Since  there  are  few,  if  any,  methodologies  available  for  conducting  enterprise  wide  strate¬ 
gic,  tactical  and  operational  planning  for  integrated  information  systems,  companies  are 
looking  to  outside  consulting  firms  for  support  in  this  area.  In  house  information  manage¬ 
ment  services  groups  are  not  trained  in  the  use  of  structured  methodological  techniques  to 
adequately  address  the  strategic,  tactical  and  operational  planning  needs  required  to  develop 
and  implement  an  integrated  information  system.  High  level  management  does  not  under¬ 
stand  information  integration  technology  and,  in  many  cases,  the  importance  of  information 
as  a  corporate  resource.  The  current  trend  is  to  purchase  hardware  and  software  as  an  infor¬ 
mation  management  solution.  The  only  problem  is  that  the  hardware  and  software  cannot 
easily  be  integrated  with  existing  systems.  Getting  started  in  the  right  direction  appears  to 
be  the  biggest  hurdle  facing  the  company  that  wishes  to  address  its  own  information  manage¬ 
ment  problems.  Strategic,  tactical,  and  operational  planners  know  that  they  want  to  reduce 
costs,  shorten  product  planning,  design  and  development  cycles,  and  improve  their  overall 
ability  to  maintain  the  product  over  long  periods  of  time.  Their  ability  to  translate  these 
goals  into  feasible  plans  often  fails  because  the  individual  methods  do  not  guide  them  in  the 
proper  overall  direction.  The  problems  that  have  been  encountered  by  planners  tend  not  to 
be  with  the  effectiveness  of  the  methodologies,  but  that  the  lack  a  structured  approach  to  the 
strategic,  tactical  and  operational  planning  for  the  design,  development  and  implementation 
of  integrated  information  systems. 

In  Appendix  B  of  this  report,  the  reader  will  find  a  node  tree  entitled  “Integrated  In¬ 
formation  System  Evolution  Process.”  The  node  tree  outlines  the  strategic,  tactical,  and 
operational  planning  activities  that  are  necessary  to  effectively  design,  develop,  and  imple¬ 
ment  an  integrated  information  system.  Following  the  node  tree  is  a  set  of  function  (activity) 
models  that  graphically  depict  the  process.  Included  with  the  node  tree  and  function  models 
the  reader  will  find  a  list  of  activity  descriptions  that  describe  what  happens  during  each 
function  depicted  on  the  models.  The  overall  intent  of  the  node  trees  and  models  is  to  the 
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illustrate  the  breath  of  activities  which  must  be  addressed  by  a  structured  approach. 

2.1.5  Common  Method  Needs 

Application  of  existing  methods  axe  often  site  specific.  In  the  following  paragraphs,  only  the 
general  problems  that  apply  to  all  applications  will  be  discussed.  The  specific  method  voids 
will  be  addressed  in  the  following  section.  The  most  obvious  method  needs  /  problems  that 
have  surfaced  during  this  analysis  are  as  follows: 

•  The  methodologies  do  not  have  user  levels  associated  with  them.  For  managers  to 
understand  and  implement  a  method,  they  must  subscribe  to  and  acquire  the  same 
level  of  training  as  the  analyst  who  will  be  responsible  for  in-depth  application  and 
analysis  work.  What  is  needed  is  alternate  syntax  for  different  levels  of  users.  For 
example,  the  process  of  application  of  the  IDEF1  method  is  effective  for  detecting 
information  which  should  be  acquired  and  managed  by  an  organization  but  is  not 
currently.  Managers  need  to  know  which  of  their  current  problems  are  caused  by  these 
information  gaps.  The  current  method  does  not  have  a  use  procedure  which  provides 
a  suggested  syntax  for  display  of  such  an  extraction  from  a  completed  model. 

•  The  integration  of  methods  has  never  been  accomplished.  This  is  primarily  because  of 
a  lack  of  establishment  of  an  engineering  formalization  of  the  syntax  and  semantics  of 
the  basic  concepts  and  theory  behind  the  techniques.  Due  to  this  integration  issue,  it 
is  difficult  and  sometimes  even  impossible  to  directly  utilize  data  from  one  modeling 
method  or  procedure  directly  to  another.  For  example,  this  is  especially  true  of  data 
transfer  from  IDEFO  to  IDEF1. 

•  The  current  methodologies  are  difficult  to  describe  beyond  the  level  of  mechanisms  on 
an  IDEFO  modeling  methodology.  The  underlying  principles  and  theory  upon  which 
the  modeling  methods  are  based  are  not  easily  recognized  at  the  application  level. 

•  Current  methods  are  very  inflexible  and  do  not  provide  the  user  with  any  options  during 
the  application  phases  of  the  methodologies.  A  user  must  conform  to  the  outlined 
procedures  prescribed  in  the  methodology  or  the  results  may  lose  their  meaning. 

•  Many  of  the  existing  methods  are  deterministic  and  do  not  provide  easy  application 
when  the  system,  functions,  and/or  information  being  modeled  are  stochastic  (or  in 
any  way  time  dependent)  in  nature. 

•  Current  methods  are  not  structured  to  allow  for  the  dynamic  properties  of  information. 
Some  provision  is  needed  for  identifying  the  age  of  data  at  the  input  side  of  the  system, 
and  to  provide  for  the  aging  process  within  the  structure  of  the  method. 
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•  Most  of  the  current  methods  have  not  been  developed  with  the  objective  of  knowl¬ 
edge  base  implementation,  Fbture  methods  must  be  developed  with  the  objective  of 
generating  and  populating  a  knowledge  bases.  It  is  critical  for  methods  to  be  made 
compatible  and/or  be  integrated  in  order  to  accomplish  this. 

•  Current  methods  have  not  been  developed  for  a  single  set  of  application  based  data 
standards.  They  all  presume  complete  autonomy  of  the  individual  application  devel¬ 
oper  to  define  his  own  private  standards. 

•  At  the  application  level,  the  concept  of  data  acquisition  for  the  population  of  a  model 
or  use  in  a  methodology  is  not  clearly  linked  to  the  data  administration  process  nor 
is  there  any  relationship  to  the  system  development  process.  As  a  result,  when  the 
design  is  implemented,  the  data  is  not  neatly  available  in  readily  accessible  files. 

•  At  the  discipline  level,  no  existing  methods  have  the  automated  support  needed  to 
improve  the  actual  model  development  decision  making  process.  Existing  tools  mainly 
provide  automated  features  that  store  a  finished  model  and/or  draw  graphics  represen¬ 
tations.  However  the  key  processes  of  classification,  consistency  and  completeness  anal¬ 
ysis,  common  data  identification,  validation  review  and  model  integration  are  largely 
ignored  This  is  a  common  problem  and  results  in  both  long  application  lead  times  for 
stand  alone  applications  and  prohibitively  expensive  integrated  systems  developments. 

•  Enterprise  analysis  procedures  cannot  take  advantage  of  the  data  produced  by  current 
methods  for  applications  engineering.  Only  after  some  form  of  data  transformation 
and/or  data  analysis  can  that  data  be  put  in  a  form  useable  for  enterprise  decisions. 

2.1.6  Component  Method  Voids 

The  following  paragraphs  describe  specific  component  method  voids  which  were  uncovered 
in  this  needs  analysis  effort. 

Systems  analysts  and  consultants  who  have  been  working  on  the  analysis,  design,  de 
velopment,  and  implementation  of  integrated  information  systems  (e.g.,  the  Air  Force  Inte¬ 
grated  Design  Support  System  (IDS)),  have  had  difficulties  mapping  information  between 
the  strategic,  tactical  and  operational  models  that  were  developed  during  each  of  the  respec¬ 
tive  activities.  This  difficulty  stems  from  the  fact  that  the  methods  that  are  available  to 
them  are  not  designed  as  an  integrated  set  nor  were  they  designed  to  support  an  information 
engineering  paradigm  for  system  development.  Also,  the  methods  fail  to  give  clear  guidelines 
on  how  to  apply  the  associated  concepts  in  the  areas  of  strategic,  tactical  and  operational 
planning  for  the  implementation  of  integrated  information  system  technology.  Most  of  the 
guidelines  that  are  available  apply  to  usage  as  requirements  specification  methods,  and  not 
as  planning,  design,  or  implemc.  ation  methods.  In  many  cases  this  is  justified  because  the 
concepts  embodied  in  the  methods  were  never  intended  to  be  applied  in  those  domains.  But 
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even  in  these  cases  the  repeated  requests  by  the  practicing  system  developers  indicates  a 
void  in  the  total  set  of  methods  required. 

The  function,  information  and  dynamic  modeling  methods  in  use  today  are  very  generic. 
They  can  be  used  for  a  variety  of  purposes.  There  are  few  guidelines  on  how  to  effectively 
collect  the  data  object  types  that  are  used  to  populate  an  integrated  information  system 
knowledge  base.  There  is  a  need  to  develop  standards  for  the  types  of  data  objects  that 
are  required  by  such  a  knowledge  base.  Most  of  the  methodologies  available  today  collect  a 
limited  set  of  data  object  types  such  as  entity  definitions,  activity  descriptions,  etc.  There 
is  a  need  for  a  much  broader  set  of  data  objects  that  includes  the  ones  that  follow: 

•  Data  Objects 

•  Time  Dependent  Data  Object  Flows 

•  Time  Dependent  Process  Flows 

•  Data  Object  Constraint  Rules 

•  Organizations 

•  Organization  Structures 

•  Project  Codes 

•  Legal  Value  Sets 

•  Data  Object  Approval  Rules 

•  Notification/Distribution  Recipients 

•  Data  Object  State  Transition  Rules 

•  Data  Object  Access  Rules 

•  Data  Object  Revision  Reason  Rules 

•  Task  Initiation  Rules 

•  Menu  Access  Rules 

•  File  Location  Rules 

No  methodologies  are  available  in  industry  today  that  can  effectively  collect,  analyze, 
define,  verify,  store,  maintain  and  display  the  semantics  (i.e.,  the  meaning  of  model  elements) 
associated  with  product  data  and  their  life  cycles.  Many  of  the  system  engineering  tools  that 
are  available  today,  process  model  element  input  in  a  syntactical  fashion,  i.e.,  they  do  not 
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interpret  the  meaning  of  model  elements.  There  is  a  need  for  tools  that  have  the  ability  to 
interpret  the  meaning  of  data,  thus,  processing  input  semantically  as  well  as  syntactically. 

To  clarify  the  point,  an  information  model  contains  syntax  such  as  boxes,  lines  and  circles, 
which  semantically  represent  entities,  relationships  between  entities,  and  entity  relationship 
cardinality.  It  is  these  semantical  representations  that  a  semantic  data  engineering  tool 
should  be  able  to  interpret. 

There  is  a  need  to  capture  information  model  relationship  types  (e.g.,  a-part-of,  an- 
instance-of,  a-kind-of,  connected-to,  is-used-for,  sends-to,  receives-from,  etc.)  that  support 
the  kinds  of  engineering  and  manufacturing  applications  that  deal  with  the  problems  related 
to  part  geometry,  product  structures,  machine  fault  diagnosis,  scheduling,  process  planning, 
etc. 

Of  equal  importance  is  the  need  to  capture  the  semantics  that  are  represented  on  function 
models,  i.e.,  the  activities  that  must  be  performed  in  a  given  sequence,  the  life  cycle  states 
that  as  the  product  data  evolves,  the  conditions  that  must  be  satisfied  and  the  mechanisms 
that  are  required  to  perform  the  activities  must  be  known.  This  information  is  required  so 
that  product  data  can  effectively  be  managed  and  controlled  during  its  life  cycle. 


2.1.7  Tbol  And  Tbol  Environment  Problems 


Several  Computer  Aided  Software  Engineering  (CASE)  computer  based  tools  have  appeared 
during  the  last  two  years.  Some  of  the  tools  are  claimed  to  support  the  strategic,  tactical,  and 
operational  levels  of  system  engineering.  Many  of  the  tools  are  developed  on  top  of  a  data 
dictionary  that  provides  some  level  of  consistency  checking  between  the  modeling  capabilities 
that  are  provided  by  the  tool.  The  tools  usually  provide  two  dimensional  graphics  capabil¬ 
ities  for  producing  data  flow,  entity  relationship,  and  system  architecture  models.  Other 
tools  provide  screen  layout  and  in  some  cases  data  base  generation  and  prototyping  capabil¬ 
ities.  These  tools  are  being  used  by  many  companies  to  provide  requirements  specification 
and  structured  design  documentation  for  application  engineering  approaches  to  information 
systems.  Section  2.3  contains  a  summary  of  the  state  of  the  art  in  CASE  tools  relevant  to 
the  information  engineering  approach  to  information  integrated  systems  development. 

Little  or  no  documentation/training  is  provided  on  how  to  apply  these  tools  for  perform¬ 
ing  strategic,  tactical,  and  operational  planning  for  integrated  information  system  technology 
or  for  carrying  out  design,  development,  and  implementation  in  an  information  engineering 
fashion.  Furthermore,  no  data  format  standards  exist  for  sharing  data  /  information  between 
tools  developed  by  different  vendors.  There  is  a  critical  need  to  identify  the  different  types 
of  data  object  types  that  are  required  by  an  integrated  information  system  knowledge  base. 
The  following  paragraphs  describe  in  more  detail  the  tool  capabilities  that  are  required  to 
support  the  evolution  and  implementation  of  information  integrated  systems: 


•  State  TVansition  Rule  Consistency  Analyzer  -  automated  support  for  capture,  repre¬ 
sentation  and  analysis  of  data  object  state  transitions  over  time  with  the  ability  to 
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indicate  precision  (months,  days,  hours,  minutes,  etc.).  This  includes  interdependency 
rule  specification,  e.g.,  data  object  “A”  cannot  change  state  unless  data  object  “B”  is 
in  state  “X”  and  data  object  “C”  is  in  state  “Y”. 

•  Data  Object  Scheduling  Simulator  -  the  ability  to  determine  the  effect  of  data  object 
scheduling  requirements  (both  qualitatively  and  quantitatively),  i.e.,  an  object  must 
be  initiated  by  a  given  date  and  completed  by  a  given  date. 

•  Performance  Simulator  -  the  ability  to  assess  the  performance  attributes  associated 
with  a  data  object,  e.g.,  speed,  dimension,  weight,  etc.  This  capability  is  needed  for 
representing  the  characteristics  of  a  mechanism  data  object  type  where  a  mechanism 
might  be  a  program,  machine,  robot,  etc. 

•  Configuration  Management  -  the  ability  to  support  model  versions,  design  alternatives, 
audit  trails,  change  notifications,  approvals,  version  control,  access  authorizations,  sta¬ 
tus  accounting,  etc. 

•  System  Simulation  of  Architecture  -  the  ability  to  provide  intra  and  inter  component 
structural  consistency  and  performance  analysis.  For  example,  a  control  model  simula¬ 
tion  would  highlight  bottlenecks  associated  with  the  inability  of  a  particular  subsystem 
configuration  to  support  the  required  data  state  transitions. 

•  Requirements  Traceability  -  the  ability  to  trace  strategic  level  requirements  through 
tactical  project  requirements  to  operation  specifications. 

•  Prototyping  Tools  -  the  ability  to  produce  rapid  prototypes  from  the  models  contained 
in  the  data  dictionary  to  validate  requirements.  For  example,  code  generation  from 
structure  models,  menus/screens  from  user  interface  models,  data  bases  from  informa¬ 
tion  models,  etc. 

•  Coding/Classification  -  the  ability  to  store  and  retrieve  data,  models,  goals,  require¬ 
ments,  specifications,  designs  or  implementations  based  upon  a  “method  defined”  or 
“user  defined”  coding  /  classification  scheme. 

•  Automated  Casebooks  -  the  ability  to  support  the  user  with  CAE  instructions  on  how 
to  use  and  apply  all  of  the  methodological  tools  provided  by  the  organization. 

•  Automated  Environments  -  the  availability  of  an  integration  framework  which  allows 
and  supports  the  use  of  multiple  tools  according  to  a  development  framework  across 
the  life  of  the  application  itself  and  over  time  in  the  integration  program. 

•  Tool  Integration  Support  -  the  ability  to  easily  map  data  objects  between  the  various 
models  supported  by  the  methodology.  For  example,  be  able  to  display  all  of  the  data 
objects  that  are  associated  with  the  data  flow  on  a  function  model  with  the  data  objects 
on  an  information  model. 
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•  System  Architecture  Design  Analyzer  -  the  ability  to  model  system  architectures  and 
identify  the  interfaces  between  the  hardware  and/or  software  components,  and  provide 
consistency  checks  and  simulation  capabilities  to  analyze  performance  characteristics 
of,  for  example,  network  response  times. 

•  Information  Model  Consistency  Analyzer  -  the  ability  to  model  complex  constraints 
and  assertions  that  can  be  analyzed  through  simulation.  For  example,  assertions  that 
affect  data  object  state  transitions,  i.e.,  interdependency  constraint  rules. 

•  Common  User  Interfaces  -  availability  of  a  consistent  interface  to  tools  for  the  system 
planner,  analyst,  designer,  implementer,  and  maintainer.  Much  effort  has  gone  into 
the  design  of  consistent  user  interfaces  for  the  end  users.  Little  or  no  standards  have 
been  established  for  the  tool  vendors.  Thus  learning  a  new  tool, is  difficult  and  time 
consuming.  Simple  presentation  style  interface  standards  as  were  developed  by  Apple 
Inc.  for  their  Macintosh  software  could  prove  very  effective. 

2.1.8  Technology  Transfer  Needs 

As  will  be  outlined  in  a  subsequent  section,  training  is  only  one  phase  of  a  major  set  of 
functions  called  technology  transfer.  Training  fits  into  the  educational  process  in  that  by 
definition  training  is  intended  to  show’  people  how  to  accomplish  a  task.  During  the  past 
decade  or  more,  training  in  the  area  of  System  Development  Methodologies  (SDM’s)  has 
been  aimed  at  placing  a  set  of  system  development  methods,  procedures  and  tools  into  the 
hands  of  the  individuals  who  will  be  implementing  them.  In  nearly  every  instance,  training 
programs  have  been  structured  to  fit  into  a  lecture  -  workbook  type  of  format.  The  typical 
student  has  been  an  individual  from  a  company  that  has  been  assigned  the  task  of  learning 
the  rules  and  syntax  of  the  methodology.  In  most  of  the  courses  the  student  has  been  given 
a  rule  book  or  manual  and  has  been  provided  writh  one  or  two  days  of  lectures  outlining 
how  to  apply  these  rules.  For  a  certain  class  of  students,  and  for  a  select  group  of  SDM’s, 
this  format  and  approach  to  training  has  provided  the  students  (users)  with  everything  they 
needed  to  know.  More  recently,  with  new  educational  needs  evolving,  the  old  standard  lecture 
-  workbook  format  has  not  been  effective  for  a  broad  enough  group  of  students  (users). 

A6  the  ICAM  SDM’s  mature,  so  should  the  tools  and  materials  used  to  train  people  in 
their  usage.  The  SDM’s  are  being  refined  and  are  no  longer  being  used  by  just  the  engineers 
and  system  analysts.  It  is  not  only  appropriate  but  required  that  individuals  at  many 
levels  of  the  corporate  organizational  ladder  receive  the  appropriate  amounts  of  training  in 
the  application  of  the  SDM’s.  Without  a  clear  understanding  of  the  tools,  upper  levels  of 
management  will  be  reluctant  to  accept  proposals  based  upon  the  results  of  the  application 
of  SDM’s.  Within  the  engineering  and  system  analysis  ranks,  appropriate  training  is  needed 
to  facilitate  an  effective  application  of  the  tools.  In  many  companies,  it  is  becoming  common 
practice  to  provide  appropriate  levels  of  SDM  training  to  persons  who  will  be  supplying  data 
for  the  development  of  the  tools  and  not  necessarily  performing  the  tool  development  itself. 
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The  three  areas  of  concern  with  regard  to  the  existing  training  methods  are: 

•  Training  Materials 

•  Training  Methods 

•  Training  Personnel 

As  mentioned  in  the  earlier  discussion,  current  training  materials  for  the  SDM’s  consist 
of  workbooks  designed  to  be  used  in  a  lecture  format.  These  materials  were  appropriate  five 
to  six  years  ago  but  may  not  be  suitable  in  the  future.  Some  attention  should  be  given  to 
the  following  concerns  for  the  development  of  future  training  materials. 

•  An  in-depth  analysis  of  the  materials  to  be  used  in  training  programs  needs  to  be 
undertaken.  The  materials  should  not  only  teach  the  mechanics  of  applying  an  SDM, 
but  should  also  provide  some  discussion  of  the  foundation  upon  which  the  tool  is  based. 

•  A  wide  range  of  case  studies  illustrating  the  use  of  the  SDM,  and  some  discussion  of  the 
problems  and  benefits  of  such  an  application  would  be  most  appropriate.  The  current 
training  material  has  limited  case  studies.  A  wide  range  of  applications  is  needed. 

•  A  lesson  guide  with  case  studies  and  working  materials  should  be  developed  for  a  wide 
variety  of  students.  For  example,  a  class  of  managers  does  not  need  the  same  level 
of  technical  foundation  of  a  tool  as  does  the  analyst.  The  lesson  guide  outline  would 
provide  an  overview. 

•  A  comprehensive  workbook  for  each  SDM,  with  the  appropriate  training  tools  for 
offering  courses  to  managers,  technicians  and  data  providers  needs  to  be  developed. 

•  Videotaped  presentations  of  successful  applications  of  an  SDM  would  be  a  significant 
addition  to  the  training  material. 

Innovative  training  methods  have  historically  not  received  a  great  deal  of  attention.  One 
study  performed  four  years  ago  under  an  ICAM  project  explored  the  possible  use  of  pro¬ 
grammed  instruction  and/or  video  tapes  for  use  in  SDM  training.  The  results  of  this  work 
indicated  that  a  standard  classroom  lecture  type  format  was  preferred  by  students,  and  was 
the  most  cost  effective  means  of  presenting  large  volumes  of  information  in  a  short  time 
period.  With  the  introduction  of  new  systems  development  concepts  and  methods,  some 
considerations  need  to  given  to  training  procedures.  For  example: 

•  Possible  uses  of  video  tapes,  video  discs  and  some  of  the  more  contemporary  training 
tools  should  be  explored  for  integration  with  the  more  traditional  lecture  formats. 
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•  Audience  partitioning  and  audience  identification  procedures  should  be  developed  to 
assure  a  high  level  of  technology  transfer.  A  major  problem  in  seminar  presentation 
is  the  mix  of  the  audience.  Very  often  SDM  seminars  are  attended  by  managers, 
technicians  and  non-technical  people  all  at  the  same  time.  Procedures  for  handling 
this  audience  mix  problem  need  to  be  addressed. 

•  A  general  set  of  rules  for  approaching  an  audience  with  SDM  topics  should  be  devel¬ 
oped.  Methods  for  introducing  written  materials  to  groups  with  varying  interests  needs 
to  be  explored  further. 

•  Establishing  an  environment  for  SDM  training  is  essential.  Determination  of  the  opti¬ 
mum  medium,  the  size,  type  of  room,  and  other  environmental  factors  which  influence 
the  learning  process  should  be  explored. 

•  Use  of  “intelligent”  tutor  programs  or  expert  modeling  support  environments  which 
provide  training  as  you  use  them  should  be  investigated. 

Many  studies  indicate  that  good  training  personnel  are  the  key  to  effective  training 
systems.  People  with  an  understanding  of  educational  tools  and  no  education  in  SDM 
would  be  weak  teachers  in  an  industry  classroom  environment.  Technicians  with  strong 
SDM  backgrounds  and  weak  teaching  skills  would  likewise  not  be  successful  in  teaching 
SDM  methods. 

•  Individuals  with  strong  teaching  backgrounds  and  the  prerequisite  tools  for  learning 
SDM  should  be  provided  with  opportunities  to  learn  and  develop  experience  in  using 
SDM  tools . 

•  A  team  approach  to  teaching  SDM  should  be  explored.  The  team  would  be  most  suc¬ 
cessful  if  a  group  of  industry  educators  could  be  brought  together  to  form  a  presentation 
seminar  team. 

In  many  cases,  training  and  education  have  been  given  only  cursory  attention  on  most 
methodology  development  projects  projects.  Training  is  the  key  to  proper  application  of 
many  of  the  tools.  It  is  only  through  the  development  of  appropriate  training  materials,  pro¬ 
cedures,  and  teaching  personnel  that  the  USEE  technology  will  be  transferred  from  written 
manuals  to  the  industry  users.  It  is  only  through  proper  education  of  the  management  of 
these  industry  users  that  they  will  be  afforded  the  opportunity  to  apply  this  technology. 

2.1.9  Needs  to  Requirements  to  a  Plan  for  Action 

The  results  presented  in  this  chapter  represent  the  synthesis  of  reported  industry  symptoms 
and  concerns  as  they  have  experienced  shortfalls  or  failings  in  existing  methods  and  tools 
within  an  information  engineering  initiative.  The  next  section  provides  va  summary  of  a 
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model  of  the  “AS  IS”  information  engineering  process  for  system  development.  This  model 
was  used  as  a  frame  work  for  validation  of  the  above  described  needs,  and  as  a  structure  for 
assessing  the  state  of  the  art  in  methods  and  tools.  In  Chapter  3  we  report  the  requirements 
which  evolved  from  these  needs  the  results  of  the  model  analysis  and  the  state  of  the  art 
findings. 
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2.2  Models  Of  The  System  Development  Process 

As  a  part  of  this  project,  two  draft  models  have  been  developed.  They  axe  identified  as  the 
Information  System  Evolution  Process  model  (ISEP-0  —  See  Appendix  B)  and  the  Integrated 
Design  System/System  Development  Process  model  (IDS/SDP-0  —  See  Appendix  C).  The 
ISEP-0  model  is  aimed  at  systematically  describing  how  to  build  and  use  Information  Systems 
Integration  shells,  such  as  an  IDS  shell.  The  ISEP-0  model  appears  in  Appendix  B  of  this 
report.  The  first  section  in  Appendix  B  contains  a  node  tree  of  the  ISEP-0  model  augmented 
with  the  mechanisms  required  to  perform  each  function.  The  second  section  of  Appendix  B 
contains  the  actual  IDEFO  model.  The  third  section  contains  the  glossary  definition  of  each 
of  the  functions  in  the  ISEP  model.  This  ISEP  model  was  developed  as  an  extension  of  the 
original  ICAM  SDPO  model  to  serve  as  a  generic  model  of  the  activities  required  to  evolve 
an  enterprise  information  system.  There  were  two  fundamental  sources  of  experience  for 
the  concepts  which  are  characterized  in  the  ISEP-0  model.  The  first  is  based  on  experience 
gained  from  the  IISS  project.  The  IISS  provided  the  basic  architecture  of  the  IDS  and 
attempted  to  demonstrate  how  heterogeneous  hardware  and  software  systems  could  support 
the  delivery  of  integrated  data.  The  second  source  was  provided  by  the  IDS  project  itself. 
The  IDS  project  is  an  application  experiment  which  actually  is  building  and  implementing  a 
prototype  IDS  using  many  of  the  concepts  from  the  IISS  testbed.  The  Rockwell  IDS  project 
involves  both  development  and  use  of  the  IDS,  and  is  expected  to  ultimately  lead  to  a  useful, 
generalized  IDS  shell.  This  model  was  then  specialized  (into  the  IDS/SDP-0)  to  highlight 
the  characteristics  of  an  IDS  based  information  integration  strategy. 

The  IDS/SDP-0,  was  developed  to  describe  the  process  of  assimilation,  customization, 
and  utilization  of  an  IDS  shell  for  the  purpose  of  focusing  the  requirements  assessment  and 
state  of  the  art  analysis  on  the  IDS  Program  and  the  use  of  its  product.  The  IDS/SDP-0 
model  was  developed  down  to  the  second/third  level  of  decomposition  with  a  detailed  node 
index.  Parts  of  the  model  are  predicated  on  real  experience,  while  other  parts  are  an  attempt 
to  describe  what  is  anticipated  to  occur  where  no  real  experience  exists.  The  model  is  also 
an  attempt  to  incorporate  a  multiplicity  of  views  regarding  how  an  IDS  (or  IDS-like)  shell 
might  be  employed  by  an  Enterprise  to  evolve,  at  its  own  pace,  toward  its  own  definition  of 
a  practical  level  of  system  integration.  Viewed  from  this  perspective,  the  IDS  shell  becomes 
simply  an  enabling  technology  to  facilitate  system  integration. 

The  purpose  of  the  ISEP-0  model  is  to  provide  an  understanding  of  how  to  build  and 
begin  to  use  an  information  integration  system,  of  which  IDS  is  an  instance.  The  IDS/SDP-0 
model  is  aimed  at  understanding  how  to  assimilate  an  IDS  (or  IDS-like)  shell,  customize  it 
to  fit  an  enterprise,  and  begin  to  use  it. 

The  remainder  of  this  section  of  the  report  presents  the  top  level  nodes  of  the  IDS/SDP- 
0  model.  In  traditional  IDEF-0  form,  the  A-2  through  A-0  representations  are  used  to 
establish  a  focus  for  the  remainder  of  the  model.  It  is  readily  apparent  that  an  assimilation 
of  this  enabling  technology  is  viewed  as  having  strategic  implications  to  the  enterprise,  and  its 
implementation  and  evolving  use  is  viewed  as  being  managed/directed  via  a  single,  long-term 
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strategic  program. 

2.2.1  IDS/SDP-0  Model 

This  subsection  contains  the  top  level  nodes  of  the  IDS/SDP-0  function  model  which  was 
used  as  a  definition  of  the  system  development  process  within  an  IDS  context.  This  definition 
was  used  to  structure  the  state  of  the  art  assessment  and  the  IISEE  requirements  definition. 
It  was  also  used  as  a  guide  in  the  development  of  the  IISEE  plan.  The  complete  IDS/SDP-0 
model  is  included  in  Appendix  C. 

IDS/SDP-0  Model  Purpose  and  Viewpoint 

•  The  purpose  is  to  represent  the  activity  framework  which  can  be  used  as  a  skeleton 
for  planning  how  to  evaluate,  customize,  and  utilize  (assimilate)  the  technology  and 
capability  comprising  and  IDS  shell. 

•  The  viewpoint  is  of  the  planner  or  manager  responsible  for  introduction  of  IDS  ca¬ 
pability  into  the  enterprise  and  the  use  of  this  capability  in  the  best  interests  of  the 
enterprise  as  a  whole. 

A-l  Manage  Enterprise  Strategic  Development 

The  very  nature  of  information  integration  vehicles  such  as  the  IDS  implies  strategic  ramifi¬ 
cations  to  an  enterprise.  While  it  is  certainly  true  that  IDS-like  capabilities  can  be  employed 
on  a  much  more  limited  scale  than  as  an  enterprise-wide  integration  catalyst,  experience 
with  such  devices  appears  to  indicate  that  the  greatest  leverage  might  be  gained  from  their 
employment  throughout  the  enterprise  as  a  whole  as  opposed  to  program  or  project  confined 
utilization.  This  might,  of  course,  require  significant  advances  in  technology  over  what  is 
commonly  (and  affordably)  available  today.  However,  with  their  strategic  potential  having 
already  been  demonstrated,  and  with  the  requisite  advances  in  technology  apparently  “in 
the  wings,”  the  decision  to  employ  IDS-like  vehicles  is  perceived  as  being  justifiably  strategic 
in  nature,  and  the  implementation  effort  is  likely  to  be  viewed  as  another  of  several  on-going 
strategic  projects  in  most  enterprises  in  the  future.  The  IDS/SDP-0  model  attempts  to  ad¬ 
dress  the  implementation  and  use  of  an  Information  Integration  shell,  and  an  IDS  shell  in 
particular,  from  this  strategic  perspective. 

A-0  Plan/Manage  Implementation  of  Strategic  Projects 

Strategic  projects  are  generally  long-term  efforts  which  contribute  to  strengthening  the  posi¬ 
tion  of  an  enterprise  with  respect  to  its  m%ket  and/or  comPetiti°n-  They  tend  to  be  “sold" 
to  executives  based  more  on  their  potential  benefits  than  on  assurances  of  cost /benefit  re¬ 
lationships  since  often  neither  the  total  cost  of  a  strategic  project  nor  its  implementation 
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Figure  2.1:  IDS/SDP-0  Context  Overview  (FEO) 

schedule  can  be  projected  with  any  appreciable  degree  of  certainty.  Funding  is  generally  pro¬ 
vided  on  an  incremental  basis  and  predicated  on  a  continuous  stream  of  positive  indications 
to  enterprise  executives  that  the  effort  warrants  additional  investment. 

Implementation  of  an  IDS-like  capability  is  likely  to  be  viewed  by  executives  as  a  strategic 
effort;  one  of  several  that  the  executive  body  of  the  enterprise  is  pursuing.  As  such,  it  is 
likely  to  be  directed  and  funded  in  a  manner  consistent  with  the  handling  of  other  strategic 
projects  in  the  enterprise.  The  IDS/SDP-0  model  reflects  this  assumption  by  treating  an  IDS 
implementation  project  as  one  “instance”  of  the  strategic  project  portfolio  of  the  enterprise. 

Plan/Manage  EDS  Implementation  Project 

In  the  broadest  terms,  the  implementation  of  the  IDS-like  capability  in  an  enterprise  is 
expected  to  track  closely  with  the  traditional  life-cycle  based  administrative  view  of  major 

projects,  that  is,  to: 

•  Understand  the  problem 

•  Implement  the  solution 

•  Improve  the  solution 
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Figure  2.3:  A-0  Plan/Manage  Implementation  of  Strategic  Projects  (FEO) 

However,  several  significant  departures  from  tradition  can  be  noted  at  the  more  detailed 
levels  of  the  IDS/SDP-0  model,  particularly  in  the  technical  portions  (A22  and  A23).  This 
is  primarily  due  to  the  perception  of  data  as  a  shareable  resource  that  is  useful  in  many 
computer  applications  and  by  the  use  of  recursive-  and  prototype-based  approaches  to  the 
development  and  use  of  IDS-like  capabilities. 

Additionally,  the  IDS/SDP-0  model  reflects  the  view  that  an  IDS  (or  IDS-like)  facility 
is  really  an  enabling  technology  directed  to  achieve  information  integration  in  complex  com¬ 
puterized  environments,  with  the  environment  evolving  slowly  towards  complete  integration 
rather  than  quickly  through  one,  large  technology  revolution.  As  a  result,  the  IDS/SDP- 
0  model  assumes  continued  refinement  and  tuning  of  the  IDS  technology  itself  during  this 
evolutionary  process. 
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Figure  2.4:  A-0  Plan/Manage  IDS  Implementation  Project 
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2.3  State-of-the-Art  Technology  Assessment 

The  objective  of  this  section  of  the  report  is  to  summarize  the  voids  and  deficiencies  un¬ 
covered  in  the  applied  state-of-the-art  (as  opposed  to  emerging  state-of-the-art)  available 
technologies.  In  this  case,  technologies  include  both  methods  (practices)  and  tools  support¬ 
ing  these  methods.  The  context  for  the  assessment  was  provided  by  three  models  of  the 
Information  System  Development  Process: 

1.  the  SDMO  Model  that  emerged  from  ICAM  Project  Priority  1701,  published  in  1985. 

2.  the  ISEPO  Model  constructed  in  support  of  the  ISEM  Project  (Reference  Appendix 
B). 

3.  the  IDS/SDPO  Model  constructed  during  the  current  project  for  which  this  report  has 
been  prepared  (See  Appendix  C).  A  description  of  the  viewpoint  and  evolution  of  each 
of  these  models  can  be  found  in  the  introductory  comments  to  Section  2.2  of  this  report. 

2.3.1  IDEFO  Model  Assessment 

Eighteen  artifacts  were  identified  as  required  for  a  complete  technology  assessment  in  support 
of  an  USEE  developement  the  first  nine  of  which  were  produced  during  this  assessment 
project  to  prepare  the  USEE  plan: 

1. 

2. 

3. 

4. 

5. 

6. 

7. 


A  matrix  displaying  which  mechanisms  were  identified  for  each  of  the  leaf  nodes  of  the 
SDMO  model  (Appendix  D). 

A  compilation  of  all  the  definitions  and  textual  references  in  the  SDMO  model  for  each 
of  the  mechanisms  in  the  model  (Appendix  E). 

A  description  of  each  kind  of  functionality  envisioned  as  comprising,  collectively,  the 
mechanisms  in  the  SDMO  Model  (Appendix  F). 

A  matrix  displaying  the  composition  of  each  mechanism  in  the  SDMO  Model  in  terms 
of  the  functionality  envisioned  as  comprising  it  (Appendix  G). 

A  list  of  tools  currently  available  and  in  active  use  which  were  envisioned  as  being 
representative  of  the  state-of-the-art  (Appendix  H). 

Tool  Fact  Sheet  (1  for  each  selected  tool)  summarizing  the  characteristics  of  each  tool 
as  advertised  by  the  tool  manufacturer/provider  (Appendix  I). 

A  matrix  displaying,  for  each  selected  tool,  the  functionality  the  tool  is  understood  to 
provide  and  the  typical  usage  of  the  tool  in  the  System  Life  Cycle  envisioned  by  the 
Manufacturer /Provider  (Appendix  J). 
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8.  A  matrix  displaying  the  degree  to  which  all  the  tools  collectively  provide  each  type  of 
functionality  overall  is  shown  in  Figure  2.5. 

9.  The  IDS/SDPO  Model  (Reference  Section  2.2). 

10.  A  matrix  displaying  which  mechanisms  were  identified  for  each  of  the  leaf  nodes  in  the 
IDS/SDPO  model;  similiar  to  artifact  #1,  but  based  on  the  IDS/SDPO  Model  instead 
of  the  SDMO  Model. 

11 .  A  compilation  of  all  the  definitions  and  textual  references  in  the  IDS/SDPO  Model 
for  each  of  the  mechanisms  in  that  model;  similiar  to  artifact  #2,  but  based  on  the 
IDS/SDPO  Model  instead  of  the  SDMO  model. 

12.  A  description  of  each  kind  of  functionality  envisioned  as  comprising,  collectively,  the 
mechanisms  of  the  IDS/SDPO  Model;  similiar  to  artifact  #3,  but  based  on  the  IDS/SDPO 
Model  instead  of  the  SDMO  Model. 

13.  A  matrix  displaying  the  composition  of  each  mechanism  in  the  IDS/SDPO  Model  in 
terms  of  the  functionality  envisioned  as  comprising  it;  similiar  to  artifact  #4,  but  based 
on  the  IDS/SDPO  Model  instead  of  the  SDMO  Model. 

14.  A  list  of  tools  currently  available  in  active  use  which  are  envisioned  as  being  represen¬ 
tative  of  the  state-of-the-art.  These  tools  will  form  the  basis  of  the  final  assessment 
conclusions.  This  artifact  is  an  extension  of  artifact  #5. 

15.  Tool  fact  sheets  (1  for  each  selected  tool)  summarizing  the  characteristics  of  each  tool  as 
advertised  by  the  tool  manufacturer /provider.  This  artifact  is  an  extension  of  artifact 
#6. 

16.  A  matrix  displaying,  for  each  selected  tool,  the  functionality  of  the  tool  is  understood 
to  provide  and  the  typical  usage  of  the  tool  in  the  System  Development  Life  Cycle 
envisioned  by  the  Manufacturer/Provider.  This  artifact  is  an  extension  of  artifact  #7. 

17.  A  matrix  displaying  the  degree  to  which  all  the  tools  collectively  provide  the  function¬ 
ality  that  appears  to  satisfy  the  envisioned  needs  of  each  IDS/SDPO  leaf  node.  This 
artifact  is  similiar  to  artifact  #8,  but  based  on  the  IDS/SDPO  Model  instead  of  the 
SDMO  Model. 

18.  A  summary  of  observed  strengths  and  weaknesses  (voids/deficiencies)  observed  in  the 
tools  representing  the  state-of-the-art,  insofar  as  they  collectively  provide  the  envi¬ 
sioned  functionality  required  by  the  mechanism  of  the  IDS/SDPO  Model. 

The  additional  artifacts  (items  ten  through  eighteen  above)  are  planned  to  be  completed 
in  the  USEE  Requirements  Project  (see  Section  3.5).  The  current  assessment  has  yielded 
aome  indications  of  the  following  major  deficiencies  in  the  state-of-the-art  technology  base: 
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ARTIFACT  8  -  COLLECTIVE  RATING  OF  TOOLS 
BY  FUNCTIONALITY  CLASS 


COLLECTIVE 

FUNCTIONALITY  CLASSES  TOOL  RATING 


FUNCTION  MODELING 

ft 

FACE  LEGEND 

N  FORMATION  MODELING 

© 

DYNAMICS  MODELING 

© 

STATE  TRANSITION  MODELING 

© 

SPECIFICATION  REPRESENTATION 

© 

(S)  .  VERY  WELL  COVERED;  NO  MAJOR  VOIDS/DEFICIENCIES  PERCEIVED 

(2)  .  GENERALLY  SATISFACTORY.  WITH  RESERVATIONS.  NO  MAJOR 

W  VOIDS,  BUT  SOME  DEFICIENCIES  PERCEIVED 

0  .  GENERALLY  ADEQUATE.  BUT  WITH  STRONG  RESERVATIONS 

^  SOME  SIGNIFICANT  VOIDS/DEFICIENCIES  PERCEIVED 

0  .  GENERALLY  POOR;  MAJOR  VOIDSOEFICIENCIES  PERCE  1 VE D 

SIMULATION  ANALYSIS 

© 

CODING  A  CLASSIFICATION 

© 

CONFIGURATION  CONTROL 

© 

PERFORM.  ANALYSIS 

LC  ARTIFACT  MANAGEMENT 

© 

DATABASE  GENERATION 

© 

SOFTWARE  GENERATION 

© 

ECONOMETRIC  ANALYSIS 

© 

CLUSTER  ANALYSIS 

© 

SURVEY SUPPORT 

© 

TEST  CASE  GENERATION 

© 

Figure  2.5:  Tool  Functionality  Matrix 
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1.  Methods  and  tools  for  determining  information  strategies  (as  opposed  to  application  de¬ 
velopment  strategies)  do  not  appear  to  be  available  from  a  broad  selection  of  suppliers. 
An  information  strategy  is  the  requisite  foundation  upon  which  successful  assimilation 
of  IDS  and  IDS-like  facilities  is  based.  Those  methodologies  and  tools  purporting  to 
provide  an  information  strategy  appear  to  have  their  roots  in  application  development 
planning,  and  generally  subordinate  their  address  of  information  to  its  use  within  a 
given  application  area.  Even  though  information  requirements  are  generally  identified 
from  an  enterprise-wide  perroective,  and  it  is  readily  evident  that  the  same  kind  of 
information  must  be  shared  by  multiple  processes/applications  in  the  enterprise,  the 
information  model  construction  appears  to  generally  be  planned  on  an  application  by 
application  basis. 

2.  Five  notable  deficiencies  appear  to  exist: 

(a)  It  is  generally  unclear  what  components  of  the  enterprise  strategy  influence  the 
composition  of  the  information  strategy,  and  in  what  manner  that  influence  is 
reflected. 

(b)  No  dear  mechanism  exists  for  determining  the  relative  importance  of  one  kind  of 
information  versus  another,  from  the  enterprise  viewpoint. 

(c)  No  clear  mechanism  exists  for  determining  the  order  in  which  information  models 
should  be  developed  as  a  foundation  for  the  conceptual  schema  of  an  IDS-like 
facility. 

(d)  No  dear  mechanism  exists  for  determining  the  best  order  of  application  develop¬ 
ment,  based  on  the  relative  importance  of  information  from  the  enterprise  per¬ 
spective. 

(e)  No  dear  mechanism  exists  for  extracting  an  evolutionary  (as  opposed  to  revolu¬ 
tionary)  migration  plan  from  the  information  strategy  that  optimizes  the  use  of 
existing  information  assets  via  an  IDS-like  facility. 

3.  Commercially  available  System  Development  Methodologies  (SDM’s)  represent  frame¬ 
works  for  building  and  maintaining  stand  alone  information  systems.  They  are  over¬ 
whelmingly  application  project  oriented.  Although  not  identified  specifically  in  the  list 
of  tools  (since  tools  are  viewed  in  this  context  as  software),  none  of  the  most  com¬ 
mercially  popular  SDM’s  that  were  reviewed  appeared  to  require  the  use  of  anything 
resembling  an  IDS-like  facility,  nor  did  they  require/facilitate  the  development/use  of 
common  data  standards  (conceptual  schema)  for  shared  data  from  the  Enterprise  per¬ 
spective.  Some,  however,  did  allow  for  the  development  of  information  models  targeted 
for  specific  applications. 

4.  Another  major  deficiency  of  SDM’s  in  general  appears  to  be  the  absence  of  any  effec¬ 
tive  means  for  assuring  correct  and  non-conflicting  requirements,  leading  to  significant 
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maintenance  costs  built  into  the  resultant  applications.  In  general,  methodology  frame¬ 
works  which  address  Information  Resource  Management  issues,  philosophies,  styles, 
etc.  from  an  enterprise  perspective  appear  to  be  almost  non-existent. 

5.  In  the  aggregate,  the  claims  made  by  tool  manufacturer /suppliers  might  lead  one  to 
assume  that  all  aspects  of  systems  development  are  adequately  addressed.  There  are, 
in  fact,  many  tools  available,  and  it  does  appear  that  every  major  aspect  of  the  System 
Development  Life  Cycle  is  addressed  by  one  or  more  tools,  from  strategic  information 
planning  to  maintenance.  However,  an  assessment  of  what  the  tools  actually  do  and 
what  the  consumer-base  (tool-users)  is  actually  experiencing,  leads  one  to  a  somewhat 
different  conclusion.  In  addition  to  the  issues  already  discussed  under  items  1  &  2, 
for  example,  there  appear  to  be  serious  deficiencies  in  supporting  the  System  Design 
Process.  Most  tools  claiming  to  provide  design  support  appear  to  do  a  much  better  job 
of  supporting  analysis.  While  these  tools  aid  in  the  capture  of  facts  upon  which  a  design 
can  be  predicated,  and  further  aid  in  capturing  the  design  itself,  few  (if  any)  provide 
much  support  in  the  actual  derivation  of  a  design.  The  process  of  design  appears  to 
remain  an  overwhelmingly  human  function. 

6.  In  terms  of  functionality  provided  (as  defined  in  Appendix  F)  some  notable  voids  and 
deficiencies  appear  to  exist,  as  follows: 

(a)  The  apparent  absence  of  a  common,  unified,  theoretic  foundation  for  modeling 
tools  as  a  class  of  objects. 

(b)  The  predominance  (in  terms  of  availability)  of  modeling  tools  that  capture  pictures 
(bit  map  storage/retrieval)  as  opposed  to  those  that  capture  facts  and  generate 
pictures  (models)  from  those  facts. 

(c)  The  rarity  of  tools  that  address: 

i.  Entity  State  Transformation 

ii.  Information  System  Simulation 

iii.  Coding  and  Classification  of  Information  system  components;  e.g.,  data,  soft¬ 
ware,  etc. 

iv.  Configuration  management  of  system  components;  e.g.,  schemas,  schema 
views/projections,  software,  etc. 

v.  Life  cycle  artifact  management;  e.g.,  function  models,  information  models, 
requirements,  specifications,  etc. 

vi.  Database  design  (as  opposed  to  simple  information  model  transliteration) 

vii.  System/information  econometric  analysis 

viii.  Cluster  analysis  (of  system/information  components) 

ix.  Survey  support 
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x.  Test  case  generation  (as  opposed  to  test  data  generation) 

xi.  Specification  generation  (from  requirements  models) 

7.  Some  of  the  currently  perceived  voids/deficiencies  may  be  due  in  part  to  the  limited 
sampling  of  tools.  It  is  entirely  possible  that  a  broader  search  would  enable  the  dis¬ 
covery  of  tool  that  adequately  address  many  of  these  issues. 

2.3.2  On  to  Concept 

The  needs,  state  of  the  art  voids,  and  the  definition  of  the  IDS  system  development  process 
were  used  as  a  basis  to  formulate  a  preview  of  the  architecture  of  an  USEE.  This  architecture 
is  presented  in  the  next  section.  It  is  an  initial  attempt  by  the  coalition  to  identify  the  form 
and  structure  of  a  solution  to  the  information  engineering  framework,  method  and  tool  needs. 
Most  importantly  it  was  developed  to  serve  as  a  structure  for  development  of  the  tactical 
plan  for  filling  the  identified  needs  and  voids. 
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2.4  Conceptual  Design  of  Structured  Methodology 

The  purpose  of  this  section  is  to  provide  a  description  of  the  requirements  for  an  USEE 
based  on  company  needs,  the  development  process  definition,  and  the  state-of-the-art  review 
results.  This  section  also  contains  a  high  level  architectural  view  of  an  USEE  and  an  overview 
of  its  intended  philosophy  of  use. 

2.4.1  Characteristics  and  Requirements 

The  requirements  for  on  IISEE  as  identified  by  the  coalition  team  associated  with  this  effort 
can  be  summarized  as  follows: 

1.  Complete  Life  Cycle  Coverage  (from  strategic  planning  through  maintenance). 

2.  Focus  on  three  schema  architecture  information  integration  strategy  as  defined  in  the 
IDS  concept. 

3.  Support  the  construction  of  the  three  schema  implementation  mechanisms  (for  those 
who  want  to  build  their  own)  and  the  installation  and  “feeding”  of  an  existing  mecha¬ 
nism  (for  those  who  want  to  implement  the  IDS  product  directly). 

4.  Adapt  to  an  organizational  “system”  context  (i.e.  accommodate  existing  organizational 
methods  and  system  environments). 

5.  Adapt  to  a  dynamic  company  environment. 

6.  Provide  methodology  and  tool  integration  mechanisms. 

7.  Provide  methodology,  tool,  and  implementation  integration  standards. 

8.  Provide  methods  for  capture  and  management  of  evolving  target  implementation  en¬ 
vironment  requirements  (known  as  “design-to”  requirements). 

9.  Provide  automated  support  for  maintenance  data  collection. 

10.  Demonstrate  faster  development  time  and  overall  lower  life  cycle  costs  through  life 
cycle  artifact  control. 

11.  Provide  continuous  migration  paths  for  the  information  system  applications. 

12.  Provide  support  for  the  elicitation  of  knowledge  /  system  description  information  / 
needs  /  requirements  from  the  user  community. 

13.  Allow  for  extensions  to  the  framework,  methods,  tools,  and  environments. 
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14.  Provide  the  capability  to  educate  users  in  the  limitation  of  an  existing  system  and  the 
implications  of  stressing  the  system. 

15.  Allow  modularity  in  the  development  approach. 

16.  Provide  tools  to  support  the  organization  of  needs,  plans,  requirements,  and  designs. 

17.  Provide  expert  system  capabilities  to  guide  techical  and  managerial  users  in  the  exe¬ 
cution  of  all  steps  within  a  framework. 

18.  Support  the  isolation  of  business  /  engineering  /  manufacturing  /  logistics  logic  and 
data  from  implementation  technology. 

19.  Provide  sufficient  capture  of  scoping,  requirements,  design,  and  implementation  deci¬ 
sion  making  rationale  to  minimize  impact  of  personnel  changes  in  the  project  team. 

Taken  together  these  requirements  for  an  IISEE  imply  that  what  is  needed  includes  not 
only  a  complete  set  of  frameworks,  methods,  procedures,  environments,  and  tools;  but  also 
an  IDS-like  environment  to  allow  system  developers  to  share  and  control  the  evolving  system 
development  data. 

2.4.2  Description  of  the  IISEE  Concept 

Much  of  the  IISEE  concept  can  be  understood  by  consideration  of  the  name  itself.  The 
first  word  Integrated  is  meant  to  imply  that  the  set  of  components  (frameworks,  methods, 
development  procedures,  computerized  environments,  and  tools)  are  design  to  fit  together  in 
such  a  way  as  to  reduce  the  effort  required  to  produce  integrated  information  systems.  The 
second  two  words  Information  System  specify  the  kinds  of  systems  the  IISEE  is  intended  to 
address.  Thus,  the  product  might  require  excessive  work  for  a  simple,  stand  alone  application. 
It  would  also  be  inappropriate  for  a  specific  material  handling  system  development,  or  a 
specialized  weapons  system  itself.  The  fourth  word  Evolution  is  meant  to  convey  the  fact 
that  the  IISEE  will  be  set  up  to  be: 

1.  Used  over  the  life  of  the  organization.  The  IISEE  must  be  expandable  to  support  the 
addition  of  new  methods  and  tools  as  they  are  developed  or  as  new  technology  dictates. 

2.  Inserted  into  an  existing  company  setting.  It  will  take  into  account  that  in  the  typical 
application  the  organization  will  be  trying  to  evolve  existing  systems  into  an  integrated 
system,  not  just  replace  existing  systems  with  new  systems. 

The  last  word  Environment  implies  that  the  frameworks,  methods,  and  development 
procedures  must  be  complimented  by  a  set  of  automated  support  tools  integrated  into  an 
automated  environment  which  maintains  the  “critical”  life  cycle  artifact  1 

'The  term  “artifact”  used  in  this  context  refers  to  information  or  data  produced  as  a  part  of  the  system 
development  process.  It  is  analogous  to  the  term  “product  data”  in  the  IDS  world. 
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Figure  2.6:  Relationship  of  USEE  to  the  Information  and  Product  Systems 

The  USEE  is  itself  a  system.  It  is  a  system  which  is  used  to  evolve  an  integrated  infor¬ 
mation  system  for  an  organization.  The  information  system  which  is  evolved  through  the 
use  of  the  IISEE  is  what  is  used  to  design,  build,  and  maintain  the  weapons  system  product. 
This  complex  set  of  relationships  is  illustrated  in  Figure  2.6.  It  is  important  to  note  that 
the  IISEE  is  indended  to  be  designed  to  be  insensitive  to  the  “changing  out”  of  the  shaded 
systems  in  that  figure. 

2.4.3  IISEE  Architecture 

The  IISEE  structure  as  currently  envisioned  is  illustrated  in  Figure  2.7.  One  of  the  most  im¬ 
portant  components  in  the  IISEE  is  the  “Guidebook.”  The  Guidebook  contains  a  description 
of  both  the  management  and  technical  development  philosophies  which  are  “assumptions”  in 
the  Framework  components.  In  other  words,  if  one  wishes  to  know  “why”  a  particular  step 
is  required,  or  why  the  sequence  of  steps  in  a  FYamework  is  the  way  it  is,  then  the  answer 
should  be  found  in  the  “Guidebook.”  Thus,  the  IISEE  is  designed  to  carry  with  it  its  own 
design  rationale!  The  coalition  associated  with  this  project  feels  that  without  such  rationale 
there  is  little  chance  of  such  a  product  being  accepted  into  widespread  use. 

The  Guidebook  would  also  contain  information  on  how  to  “size  up”  a  particular  de- 
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velopment  situation  (i.e.  what  landmarks  to  look  for),  and  how  to  choose  an  appropriate 
Framework  for  the  situation.  The  complexity  of  making  such  a  decision  is  the  reason  for  the 
need  (identified  by  the  coalition)  to  accompany  the  Guidebook  with  an  expert  system  which 
would  assist  in  such  decision  making.  There  is  another  intended  function  for  this  knowledge 
based  system:  to  help  the  user  when  he  finds  that  his  initial  selection  of  a  framework  was 
incorrect  and  he  must  switch  between  frameworks.  This  could  happen  in  the  middle  of  a 
project  or  could  be  a  natural  result  of  the  evolution  of  the  organization  over  time. 

The  next  major  component  of  the  USEE  is  the  collection  of  “frameworks” .  A  framework 
can  be  thought  of  as  being  analogous  to  a  “script”  or  even  a  recipe.  The  framework  contains  a 
“Development  Procedure,”  a  definition  of  the  organizational  skills  that  will  be  required,  and 
the  particular  “Methods”  chosen  from  a  set  of  methods  which  will  be  utilized  in  the  various 
steps  of  the  Development  Procedure.  It  is  anticipated  that  there  will  probably  be  specialized 
“Method  Use”  procedures  associated  with  a  Framework  which  specialize  the  use  of  the  results 
of  a  particular  method  in  the  context  of  the  framework.  The  Development  Procedure  will 
be  broken  into  phases,  steps,  and  tasks.  The  tasks  describe  specific  activities  which  must  be 
undertaken  by  the  participants,  the  steps  represent  significant  technical  decision  points,  and 
the  phases  indicate  key  management  decision  points  and  milestones. 

The  next  major  component  of  the  IISEE  is  the  “System  /  Software  Factory”  (SSF).  The 
purpose  for  prepending  the  term  System  is  to  emphasize  the  point  that  the  computerized  en¬ 
vironment  and  tools  contained  therein  will  eventually  cover  all  of  the  activities  from  strategic 
planning  through  maintenance  of  the  system.  The  utilities  contained  in  the  “Computerized 
System  Development  Environment”  (SDE)  component  of  the  IISEE  axe  described  in  Section 
3.3  of  this  report.  Ultimately,  the  “tool  crib”  of  this  factory  will  contain  a  complete  set  of 
power  tools  for  the  system  developers. 

The  last  major  component  of  the  IISEE  is  the  “Technology  Transfer”  mechanisms  which 
must  be  put  in  place.  These  components  are  important  not  only  to  get  the  IISEE  into  the 
organization  in  the  first  place,  but  also  to  propagate  its  use  throughout  the  organization. 
A  description  of  the  needed  elements  of  this  component  is  contained  in  Section  3.4  of  this 
report. 
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Chapter  3 

Plan  for  Development  of  Structured 
Frameworks 


The  purpose  of  this  chapter  is  twofold.  The  first  objective  is  to  summarize  the  requirements 
for  an  USEE.  The  second  is  to  provide  a  plan  for  IISEE  development.  This  plan  (if  carried 
out)  will  provide  the  evolution  of  an  enabling  technology  which  will  (with  existing  available 
methodologies  and  automated  tools)  provide  an  IISEE  for  organizations  to  use  to  imple¬ 
ment  and  maintain  information  integrated  engineering  and  manufacturing  systems.  Section 
3.1  presents  a  summary  justification  for  the  IISEE  component  and  framework  development 
within  the  context  of  IDS.  Section  3.2  identifies  the  requirements  for  framework  and  compo¬ 
nent  method  developments  for  an  IISEE.  Section  3.3  identifies  requirements  for  automated 
tools  and  environments  to  support  the  application  of  the  framework  and  component  methods. 
Section  3.4  identifies  the  technology  transfer  efforts  required  to  support  the  dissemination  of 
the  results  of  this  effort  and  facilitate  industry  acceptance  and  usage.  Section  3.5  provides  a 
series  of  project  descriptions,  with  time  and  resource  estimates,  for  the  development  of  the 
enabling  technologies  needed  to  fulfill  the  requirements  identified  in  the  sections  3.1  through 
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3.1  IISEE  Program  Plan  Rationale 


The  purpose  of  this  section  is  to  provide  a  summary  rationale  for  proposed  IISEE  develop¬ 
mental  projects.  The  projects  in  the  actual  plan  itself  are  organized  around  technical  thrust 
areas  (see  section  3.5).  This  organization  is  preferable  for  program  management  purposes, 
but  it  tends  to  obscure  the  logic  and  direction  behind  the  IISEE.  This  section  is  meant  to 
clarify  those  issues. 

One  of  the  first  activities  of  this  project  was  to  acquire  as  much  information  as  was 
possible  on  a  previous  project,  “Systems  Engineering  Methodology”  (SEM),  which  was  a 
part  of  the  Air  Force  Integrated  Computer  Aided  Manaufacturing  (ICAM)  Program.  It  was 
hoped  that  the  architectures  from  this  project  and  much  of  the  thinking  which  went  into 
the  component  methods  tools  and  environments  from  this  program  could  be  directly  built 
on  the  IISEE.  As  i6  evident  from  the  method  and  tool  state  of  the  art  study  (see  chapter  2 
and  most  of  the  appendices),  we  also  desired  the  IISEE  to  build  on  the  current  state  of  the 
art  in  commercially  available  methods  and  tools. 

While  to  a  large  extent  our  intuitions  were  correct,  there  appeared  to  be  an  obvious  shift 
in  logic  behind  the  systems  which  those  earlier  programs  and  commercial  products  were 
meant  to  service  and  the  systems  that  the  IDS  program  has  envisioned.  The  emphasis  of 
most  of  the  existing  tools  and  the  SDP  models  of  the  SEM  project  was  on  application  engi¬ 
neering.  But  the  IDS,  and  the  industry  in  general,  is  moving  away  from  the  “one  at  a  time” 
applications  engineering  toward  a  new  approach  where  applications  are  viewed  as  a  part  of 
an  environment.  The  overriding  theme  of  this  new  concept  is  “common  data  standards”  and 
the  sharing  of  common  data.  This  is  not  a  revolutionary  concept  as  information  integration 
thrusts  emerged  over  ten  years  ago.  The  recognition  by  industry  of  the  need  for  a  shift  in 
logic  relative  to  the  methodology  by  which  information  systems  are  evolved  is  emerging. 

Just  as  John  Zachman  applied  the  similarity  between  architectures  for  buildings  and  in¬ 
formation  systems  architectures,  a  useful  parallelism  can  be  drawn  between  this  new  shift 
in  logic  and  community  planning.  The  concept  of  community  planning  revolves  around  the 
notion  that  there  are  certain  elements  of  our  environment  which  affect  the  entire  community. 
These  elements  are  the  responsibility  of  the  entire  community.  The  effect  of  this  recognition 
was  the  organization  of  community  standards.  These  standards  changed  the  design  and  de¬ 
velopment  approaches  which  can  be  used  in  the  community  (even  to  the  point  of  constraining 
the  architectural  alternatives  of  the  designer  of  buildings  in  that  area).  A  similar  impact 
exists  in  the  information  engineering  approach  to  applications  development  within  an  IDS. 
No  longer  can  all  of  the  decisions  regarding  an  applications  structure  and  use  of  data  be 
made  in  isolation.  The  new  paradigm  requires  that  the  application  developer  have  access  to 
a  framework  for  structuring  his  activities  in  the  context  of  the  overall  information  integration 
program. 

With  these  concepts  in  mind  the  IISEE  development  plan  (see  Section  3.5  of  this  report) 
evolved  to  address  the  following  critical  questions: 
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1.  What  are  the  critical  methods  for  information  engineering? 

2.  What  i6  an  IDS  architecture? 

(a)  What  is  the  critical  functionality? 

(b)  What  are  the  information  and  technology  concepts  and  implications? 

3.  What  is  the  integration  framework  methodology  for: 

(a)  Implementing  an  IDS  architecture  in  my  environment? 

(b)  Customizing  the  Rockwell  architecture? 

(c)  Evolving  applications  in  an  IDS  architecture? 

4.  What  is  an  IISEE  and  how  does  it  relate  to  the  IDS  architecture? 

5.  What  technology  will  the  IISEE  provide  for  planning  and  management  of  an  IDS 
implementation  program? 

6.  What  technology  will  the  IISEE  provide  for  project  management  in  the  IDS  environ¬ 
ment. 

Sections  3.2  through  3.4  provide  a  summarization  of  the  requirements  implied  by  these 
questions,  the  needs  analysis  activities,  and  the  TAP  inputs.  Section  3.5  contains  the  initial 
IISEE  program  plan  which  addresses  these  needs  and  requirements.  It  is  expected  that  this 
plan  will  evolve  considerably  between  now  and  its  eventual  funding,  but  every  journey  begins 
with  a  single  step. 
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3.2  Component  Methods  and  Framework  Recommen¬ 
dations 

The  following  subsections  summarize  the  framework  and  component  methods  requirements 
which  are  addressed  in  the  USEE  Program  plan  presented  in  Section  3.5  of  this  report. 

3.2.1  Framework  Requirements 

There  are  several  ways  to  categorize  the  needed  integration  framework  developments.  Our 
justification  and  rationale  is  based  upon  analysis  of  the  needs  and  voids  described  in  Chaper 
2  of  this  report.  The  following  are  the  target  system  application  types  which  must  be 
supported  by  the  integration  framework  developments  followed  by  the  required  organization 
profiles  which  must  be  supported. 

1.  Target  system  application  types: 

(a)  CAD  /  CAE  system  development 

(b)  Engineering  Data  Management  and  Control  system  development 

(c)  Three  schema  architecture  based  information  integration  support  system  devel¬ 
opment. 

(d)  etc. 

2.  Target  user  organization  size  and  profiles: 

(a)  Large  DoD  prime  contractors 

(b)  First  tier  DoD  subcontractors 

(c)  Second  tier  DoD  subcontractors 

(d)  Large  commercial  corporations 

(e)  Small  businesses 

(f)  Systems  consulting  organizations 

3.2.2  Extensions  to  Existing  Component  Methods 

Most  of  the  recommendations  associated  with  the  existing  methods  center  around  the  fol¬ 
lowing  three  areas: 

1.  Formalization  of  definition  and  syntax. 

2.  Provision  for  improved  training  materials  and  mechanisms. 

3.  Development  of  the  “Use”  procedures  (i.e.  how  to  use  the  results  of  a  method  appli¬ 
cation  once  you  have  invested  in  those  results). 
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3.2.3  New  Component  Methods 

Even  with  the  large  number  of  available  methods  in  the  market  place,  the  experience  of  the 
coalition  team  associated  with  this  project  and  the  ongoing  IDS  project  identified  a  number 
of  voids  which  need  to  be  filled.  The  following  list  identifies  a  number  of  methods  which 
must  be  developed  to  fill  technological  and  operational  voids: 

1.  Activity  state  models 

2.  Data  state  models 

3.  Data  object  flow  timing  descriptions 

4.  Process  flow  timing  descriptions 

5.  Organization  structure  and  flow  of  control  models 

6.  Constraint  specification  rule  languages 

7.  Domain  specification  languages 

8.  System  architecture  models 

9.  Implementation  environment  models 

10.  Organization  objectives  and  goals  alignment  methods 

11.  Information  and  business  strategy  alignment  methods 

12.  Data  costing  methods 

13.  Project  prioritization  methods 

14.  Project  costing  methods 

15.  Method  for  information  integration  of  methods 

16.  Mechanism  (function,  structure,  and  performance)  models 

17.  User  interface  models 

18.  System  design  logic  models 

19.  Schedule  modeling  relationships  between  data  and  activity  objects  methods 

20.  Computer  system  architecture  describing  and  modeling  methods 

21.  Conceptual  to  internal  schema  mapping  methods 
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22.  Design  of  external  schemas  and  external  to  conceptual  schema  mapping  methods 

A  general  requirement  on  any  new  component  method  is  that  where  possible  it  should 
be  designed  as  an  extension  to  an  existing  method.  Another  general  requirement  on  any 
method  development  is  that  the  formalism  for  that  method  be  developed  in  conjunction 
with  the  discipline  and  use  components.  These  requirements  have  been  mapped  into  a  series 
of  development  projects  under  the  “Component  Methods”  thrust  in  Section  3.5  of  this  report. 
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3.3  Computerized  Environment  /  Tool  Requirements 

Existing  commercial  tools  address,  to  varying  extents,  many  of  the  functionality  classes 
needed  to  support  an  IDS-like  system  development  process  (see  Section  2.4).  Specific  voids 
within  these  classes  are  relativel  '  straight  forward  to  identify  and  advanced  plans  for  method¬ 
ological  completion  can  be  constructed.  However,  the  overiding  flaw  that  permeates  available 
support  tools  is  the  complete  lack  of  an  integrating  environment,  and  a  unifying  prescrip¬ 
tive  methodology  for  integrating  environments  and  tools.  The  situation  is  akin  to  carefully 
putting  together  a  design  team  for  a  project,  and  then  locking  each  member  in  a  room  with 
no  means  of  communication.  Because  of  the  importance  of  the  environmental  question,  this 
section  is  organized  along  the  lines  of  environmental  support  versus  specific  component  tool 
support. 

3.3.1  Integrated  Computer  Support  Environment  Requirements 

An  overall  model  of  an  adequate  environment  includes  components  that  are  targeted  for 
development  and  components  targeted  for  operation.  There  must  be  communication  between 
the  two,  and  there  will  be  some  overlap.  However,  an  idealized  model  can  be  visualized  in 
Figure  3.1.  Such  a  System  Development  Environment  (SDE)  integrates  tools  and  their  work 
products  across  the  entire  development  life  cycle.  A  meaningful  integrated  environment  must 
provide  a  uniform  user  interface.  Ultimately  it  provides  a  conceptual  framework  for  the  user. 
A  methodology  must  be  provided  for  controlled  evolution  of  the  environment  as  hardware, 
software,  and  methodologies  change.  The  environment  should  support  team  interaction 
among  developers  with  electronic  means  of  visual  communication  and  electronic  dialog.  The 
embodying  methodology  of  the  environment  should  support  both  top-down  and  bottom-up 
development,  constraints,  software  development  organization,  and  system  management.  For 
productivity  issues,  the  environment  should  support  reusability.  A  cataloging  and  retrieval 
mechanism  is  neccessary  to  accomplish  this  goal. 

Hardware  /  Operating  System 

The  most  visible  characteristic  of  the  SDE  has  to  do  with  hardware  support,  which  is  no  more 
homogeneous  than  the  tasks  to  be  performed  in  such  a  comprehensive  and  ongoing  effort. 
The  following  items  are  an  indication  of  the  range  of  hardware  support  that  is  needed. 
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Networking 

Networking  capabilities  that  will  allow  communication  among  a  multitude  of  dissimilar  ma¬ 
chines  is  a  necessity.  Further,  such  communication  must  not  be  restricted  to  file  transfers, 
but  must  also  include  communication  among  databases  and  processes. 
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Figure  3.1:  Ideal  Environment  Model 
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Window  Support 

The  much  touted  capability  for  windowing  is  not  overly  critical  in  this  context,  particularly 
in  the  development  phases.  It  is  a  gross  waste  of  human  effort  to  expect  a  developer  to 
work  with  a  complex,  multifaceted  system,  and  to  only  be  able  to  see  one  aspect  at  a  time. 
A  simple  example  is  the  ability  to  look  at  a  section  of  source  code  in  one  window  while 
viewing  the  execution  of  the  code  in  a  second  window.  Adherence  to  the  X-window  standard 
is  recommended. 

Shared  Development  Hardware  (specialized  e.g.  Lisp  machines,  workstations) 

The  Lisp  machines  have  come  to  be  popularly  identified  as  Artificial  Intelligence  Worksta¬ 
tions.  However,  the  history  of  work  in  AI  has  somewhat  fortuitously  yielded  a  by-product 
of  tremendous  potential  for  IDS-like  projects  -  the  Lisp  machine  environment.  This  envi¬ 
ronment  has  something  to  do  with  the  Lisp  language,  but  a  great  deal  more  to  do  with  a 
well  planned  work  environment.  The  first  underlying  theme  is  that  the  environment  tracks 
and  “understands”  activity  in  a  number  of  cooperating  processes  which  can  be  operating 
conceptually  in  parallel.  Thus,  for  example,  compilation  can  take  place  directly  from  one 
or  more  editor  buffers,  mail  can  be  sent,  documentation  can  be  inspected,  and  many  other 
activities  can  take  place  as  the  user  sees  fit  to  move  among  them.  The  second  underlying 
theme  is  that  the  coordination  scheme  is  for  the  benefit  of  one  user  who  must  make  progress 
on  many  related  fronts  at  once.  Thus,  the  machine  type  is  normally  a  one  user  at  a  time 
arrangement,  although  a  small  group  of  people  may  actually  utilize  the  machine  in  sequence. 
The  ability  to  tailor  individualized  “worlds”  facilitates  the  sequential  use  of  the  machine  by 
multiple  users. 

The  increase  in  developer  productivity,  particularly  during  the  design  and  engineering 
phases  when  prototyping  cycles  are  the  rule,  is  so  substantial  that  efforts  to  better  integrate 
the  hardware  type  with  more  traditional  types  should  required. 

Personal  Computer  Hardware 

Personal  computer  hardware  definitely  has  a  place  in  the  process,  both  as  a  workspace  for 
an  individual  to  try  out  ideas  and  as  a  communication  device  within  the  overall  system. 
Mobility  and  immediate  availability  are  primary  assets  of  the  personal  computer. 

Multi-user  Hardware 

Multi-user  hardware  in  general  refers  to  the  class  of  mini  and  mainframes  that  are  industry 
the  workhorses.  For  tasks  (such  as  coding  of  large  systems)  that  must  proceed  in  parallel 
and  are  well  defined,  they  are  the  machine  of  choice.  The  multi-user  characteristic  is  critical 
in  providing  for  configuration  control. 
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Delivery  Hardware 

Delivery  hardware  must  normally  have  the  multi-user  characteristic.  Of  course,  physical 
characteristics  that  affect  execution  speed  and  storage  access  become  critical  in  this  envi¬ 
ronment.  The  major  point  to  be  noted  is  that  the  characteristics  that  make  hardware  fit  for 
a  delivery  vehicle  are  quite  different  than  those  needed  during  development,  although  the 
same  machines  have  traditionally  been  used  for  both  development  and  delivery. 

User  Support 

One  goal  of  an  integrated  environment  is  to  support  the  user  with  as  much  automation  as 
possible.  Clerical  and  mundane  tasks  should  be  machine  mediated.  The  machine  should 
be  able  to  supply  the  user  with  successive  steps  from  the  applicable  integrating  framework 
and  assistance  both  in  performing  these  steps  in  their  work  activity  on  demand,  and  in 
maintaining  the  status  of  his  progress  against  the  task  set. 

User  support  issues  run  throughout  the  development  and  delivery  environment,  and  are 
emphasized  in  the  hardware  section.  Nevertheless,  several  user  support  characteristics  that 
are  specifically  in  the  software  domain  can  be  identified. 

Common  User  Interfaces 

User  interfaces  should  have  a  common  style,  regardless  of  life  cycle  phase,  in  terms  of  such 
aspects  as  keystroke  sequences,  use  of  menus,  command  names,  method  of  accessing  back¬ 
ground  information,  and  method  of  moving  around  in  the  environment.  The  benefit  of  a  com¬ 
mon  style  is  evidenced  by  the  success  of  the  Apple  Macintosh  interfaces.  The  commonality 
of  program  interaction  renders  paper  copy  of  system  documentation  virtually  superfluous. 

User  Profiling  Capability 

The  user  profiling  capability  is  important  in  the  development  stage  to  enhance  the  efficiency 
of  developers  by  allowing  individually  tailored  environments  and  to  aid  in  project  man¬ 
agement  by  monitoring  and  controlling  access  to  project  components.  It  is  important  both 
to  control  access  to  information  and  to  allow  for  the  formulation  of  individualized  query 
responses. 

Online  Documentation 

Documentation  of  system  functions  and  system  software  should  be  readily  available  online. 
Additionally,  at  least  the  syntax  and  procedures  associated  with  specific  methods  that  are 
being  used  should  be  well  documented  online.  Access  should  be  provided  by  choice  of  topical 
index  and  information  at  progressively  greater  levels  of  detail  should  be  provided. 
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Life  Cycle  Artifact  Management 

One  of  the  most  often  discussed  issues  of  system  development  is  the  failure  of  a  project 
to  capture  the  corporate  history  of  system  development.  This  shortcoming  is  particularly 
obvious  during  the  maintenance  phase.  All  artifacts,  including  requirements,  specifications, 
designs,  associated  documentation  and  interaction  over  such  artifacts  needs  to  be  captured. 
Requirements  traceability  would  be  enhanced  if  the  LCA  management  system  properly  re¬ 
lated  system  artifacts. 

Configuration  Management  Utilities 

Configuration  management  is  that  part  of  the  life  cycle  artifact  management  system  that 
handles  versions  and  change  control  of  emerging  and  evolving  system  artifacts.  The  under¬ 
lying  notion  is  that  artifacts  must  be  identified,  collected,  and  controlled  in  order  to  assure 
proper  distribution  of  the  finished  system  and  its  supporting  work  products,  as  well  as  to 
assist  in  evolution  of  the  product. 

Integration  Utilities  (inter-methodology,  intra-methodology) 

Integration  utilities  assure  smooth  transitions  across  the  life  cycle  phases  for  both  the  de¬ 
veloper  and  artifact  being  developed.  For  instance,  the  specification  methodology  should 
interface  cleanly  with  the  design  methodology.  That  is,  the  output  of  the  specification 
methodology  should  be  the  input  driver  for  the  design  methodology. 

3.3.2  Component  Ibol  Requirements 

Component  tools  are  those  individual  tools  that  support  specific  functions  within  the  systems 
development  process.  They  should  be  used  within  an  environment  that  is  cognizant  of  their 
functional  role  and  supportive  of  tool  integration.  For  each  method  in  the  USEE  framework 
a  component  tool  is  needed  for: 

1.  Support  of  data  collection 

2.  Support  of  model  representation  generation  and  display 

3.  Storage/retrieval/printing  of  models 

4.  Integration  of  method  results  into  the  Life  Cycle  Artifact  database 

Based  upon  the  results  of  the  state-of-the-art  review  presented  in  2.3  there  are  many 
component  tools  which  are  already  commercially  available.  To  use  these  tools  in  an  1ISEE 
automated  environment  would  at  a  minimum  require: 

1.  The  definition  of  interface  standards 
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2.  The  integration  of  the  tool  concepts  into  the  IISEE  Conceptual  Schema 

As  can  be  seen  from  the  survey  results,  many  existing  tools  do  not  enforce  rule  method¬ 
ology.  Rather,  they  provide  drafting  and  text  management  support.  The  strategy  for  com¬ 
ponent  tools  that  we  are  recommending  is  as  follows: 

1.  Develop  a  set  of  modeling  tool  generation  utilities  which  can  be  used  to  build  new 
tools. 

2.  Define  a  set  of  data  exchange  standards  with  existing  tool  vendors  so  that  existing 
tools  can  be  integrated  into  an  IISEE  structure. 

3.  Using  the  modeling  tool  generation  utilities,  develop  prototype  tools  for  the  following 
high  priority  application  areas  where  no  existing  tools  are  available. 

(a)  Data  state  modeling 

(b)  Process  modeling 

(c)  System  architecture  capture  and  simulation 

(d)  Coding,  classification,  and  cluster  analysis  for: 

i.  needs 

ii.  requirements 

iii.  By  stem  components 

(e)  Conceptual  Schema  design  generation  from  information  models 

(f)  Rapid  prototyping  of  external  schemas 

(g)  Workstation  based  data  collection  and  summarization  tool 

(h)  Rapid  prototyping  of  IDS  applications 

In  addition  to  the  above  tool  recommendations  there  are  a  number  of  additional  tools 
which  require  the  application  of  expert  system  technology.  These  will  be  presented  in  the 
following  section. 

3.3.3  Knowledge  Based  Tool  Requirements 

Applications  for  Knowledge  Based  Systems  (KBS),  which  were  identified  by  the  project,  may 
be  generally  classified  as  those  applications  which  support  an  IDS  development  cycle,  and 
those  which  augment  the  IDS  capabilities.  That  is,  those  which  aid  in  building  /  maintaining 
an  IDS  based  environment  and  those  which  would  be  part  of  the  IDS  itself.  The  emphasis 
in  this  section  is  on  knowledge  based  development  support  tools  since  the  latter  tend  to  be 
domain  specific. 
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1.  Modeling  support  is  a  major  area  that  could  benefit  from  KBS  support.  The  model 
building  tools  on  the  market  (primarily  PC  based)  have  mainly  addressed  the  syntax, 
and  to  some  extent  the  procedural  components  of  a  method.  Generally,  a  tool  has  no 
notion  of  the  underlying  concepts  and  theory  of  the  method  or  of  the  reasonable  usage 
of  the  method.  Thus,  it  neither  enforces  the  theory  nor  anticipates  appropriate  model 
use.  This  is  a  fertile  area  for  knowledge  based  augmentations  to  the  model  building 
process.  Samples  of  rule  based  buttressing  that  can  be  envisioned  are: 

(a)  The  method  semantics  that  govern  the  modeling  process  should  be  enforced.1 
Otherwise,  there  is  no  way  of  assuring  that  the  method  that  is  administratively 
espoused  is  the  one  actually  used.  An  information  model  may,  for  instance,  easily 
have  the  visual  appearance  of  an  IDEF1X  model  without  being  an  IDEF1X  model. 
Actually,  some  tools  on  the  market  do  offer  semantic  support  for  some  types  of 
models  (the  AutoIDEFO  tool,  for  example).  However,  the  more  common  case  is 
that  drafting  tools  with  little  or  no  consistency  checking  are  all  that  is  available. 

(b)  The  usage  of  a  viable  model  will  continue  long  after  its  completion.  Certainly 
query  facilities  for  the  USEE  in  a  natural  language  (see  Chapter  5)  format,  or 
perhaps  in  a  graphical  pattern  matching  format,  should  be  provided. 

(c)  Construction  of  the  necessary  models  required  to  support  planning,  analysis,  de¬ 
sign  and  construction  and  evolution  of  an  IDS  implementation  will  require  a  level 
of  organizational  participation  which  is  far  in  excess  of  that  supportable  by  trained 
modelers.  A  model  data  acquisition  and  model  prototyping  support  utility  base 
on  use  of  natural  language  discourse  processing  is  required  to  allow  the  domain 
experts  to  more  productively  contribute  to  the  definition  effort. 

(d)  Much  of  the  information  contained  in  a  model  will  be  useful  in  other  contexts  - 
models,  programs,  and  databases.  Systems  able  to  intelligently  extract  informa¬ 
tion  from  a  model  that  is  relevant  in  another  context  would  be  extremely  valu¬ 
able.  Today,  a  large  systems  development  project  will  likely  include  at  least  the 
construction  of  function  models,  information  models,  process  models,  and  data 
structure  models;  but  the  relationships  among  the  models  are  manually  derived 

'The  question  of  enforcement  of  model  semantics  is  complicated  by  the  consideration  of  the  various  usage 
modes  in  which  a  person  may  do  modeling.  One  major  usage  differentiation  has  to  do  with  the  scope  of  the 
modeling  effort;  that  is,  a  person  will  typically  approach  the  problem  differently  depending  on  whether  one  is 
building  a  small,  “personal”  model  or  is  contributing  to  a  large  scale  company  model.  An  effective  tool  must 
be  able  to  differentiate  between  these  modes.  A  second  major  differentiation  has  to  do  with  the  phase  of  the 
modeling  effort  underway.  During  the  early  phases,  it  is  unreasonable  to  insist  on  completeness  and  absolute 
consistency.  Rather,  inconsistencies  should  be  flagged  at  appropriate  points.  Also,  in  some  methods  (IDEF1 
for  instance),  the  syntax  and  semantics  that  is  allowable  in  early  phases  may  differ  from  the  final  correct  syntax 
and  semantics.  The  life  of  a  model  does  not  end  with  the  completion  of  its  construction.  Actually,  a  model, 
like  software,  may  continue  to  slowly  evolve  long  after  its  initial  “completion.”  Thus,  a  maintenance  mode  of 
operation  should  be  provided. 


X."  KT.  H.^  Xfl  M-"»  *T  XT.  JV.  *C"-  V.  VtX’T' 


CHAPTER  3.  PLAN  FOR  DEVELOPMENT  OF  STRUCTURED  FRAMEWORKS  71 

by  modeling  experts  -  if  such  are  available.  Not  only  are  such  people  scarce,  but 
also  their  knowledge  goes  with  them  when  they  leave  the  project. 

It  was  pointed  out  in  Section  1.1  that  a  method  may  have  multiple  presentations, 
each  of  which  may  be  useful  depending  on  the  orientation  of  the  viewer.  A  natural 
use  for  a  knowledge  based  system  would  be  the  formulation  of  a  model  in  its 
various  guises. 

It  was  also  pointed  out  in  Section  1.1  that  a  methodology  usually  encompasses  a 
family  of  related  methods,  e.g.  both  ENALIM  and  IDEFl  are  methods  within  the 
information  modeling  methodology.  The  “translation”  of  a  model  associated  with 
one  method  to  a  model  in  the  style  of  another  method  is  far  more  difficult  than 
generation  of  multiple  presentations,  since  the  information  content  of  the  two  will 
not  be  exactly  the  same.  A  heuristic  solution  to  the  problem  seems  to  be  the  most 
promising  approach,  since  it  is  possible  to  identify  rules  of  thumb  for  converting 
some  constructs  within  one  model  to  corresponding  constructs  in  another.  Part 
of  such  a  system  would  be  the  selective  prompting  of  a  user  to  direct  attention  to 
problem  areas.  That  is,  it  may  be  easier  to  identify  a  problem  than  to  correct  it. 
In  fact,  it  may  not  be  possible  to  correct  a  problem  automatically  because  of  an 
information  or  relational  gap. 

Validation  of  a  model  could  be  supported  by  a  system  to  either  generate  an  English 
statement  of  the  business  rules  that  are  implied  by  a  model,  or  to  incorporate 
statements  of  business  rules  into  a  model. 

2.  The  long  range  view  of  the  IISEE  project  includes  an  expectation  that  a  classification 
structure  of  environment  types  will  be  identified.  For  example,  the  implementation 
of  an  IDS-like  system  in  the  context  of  a  flexible  manufacturing  cell  would  imply  a 
certain  type  of  development  procedure.  Given  the  type  identification,  a  development 
framework  must  then  be  configured  for  an  individual  customer.  An  expert  system 
that  utilized  a  question  and  answer  format  to  customize  a  framework  for  a  company 
is  required.  Of  course,  this  suggestion  anticipates  the  development  of  human  expertise 
in  this  area.  The  question  and  answer  format  would  appear  to  be  necessary  in  order 
to  gather  specific  company  or  development  personnel  information.  The  question  of 
acceptable  risk  will  be  highly  company  and  project-  and  time-specific. 

3.  The  implementation  of  an  IDS-like  system  implies  a  substantial  learning  process  on  the 
part  of  the  team  members.  In  particular,  selected  methods  and  method  presentations 
must  be  learned.  Applicable  standards  must  also  be  learned  by  project  personnel. 
Intelligent  tutorials  that  accommodate  the  learning  style  of  the  user  could  greatly 
speed  this  process.  The  observation  that  most  modeling  efforts  involve  a  classification 
activity  leads  to  one  major  contribution  of  such  tutorials  -  the  provision  of  practice  / 
critique  cycles,  which  are  needed  because  it  simply  takes  practice  to  teach  someone  to 
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be  good  at  classification.  The  combination  of  good  tutorials  with  online  documentation 
is  clearly  needed. 

4.  Knowledge  based  project  management  tools,  for  instance,  that  would  allow  a  “what  if’ 
capability  will  be  required  as  the  information  engineering  paradigm  forces  the  project 
manager  to  consider  factors  outside  of  the  time  frame  and  technical  scope  of  a  single 
application  development.  The  ability  to  address  resource  delays,  resource  shortages, 
the  addition  of  tasks,  and  relation  of  the  time  parameters  in  such  a  complex  domain 
is  essential.  The  ability  to  be  able  to  assess  local  decisions  relative  to  the  “current” 
information  system  and  business  strategic  plans  and  critical  success  factors  is  required. 

5.  One  of  the  greatest  headaches  for  a  project  manager  has  to  do  with  trying  to  remember 
not  just  what  decisions  were  made,  but  why  they  were  made  at  the  time.  An  illustrative 
scenario  involves  a  meeting  of  project  personnel  in  which  pros  and  cons  for  a  decision 
are  presented.  The  manager  listens  and  makes  a  decision,  which  is  recorded.  However 
the  rationale  for  the  decision,  and  the  work  that  went  into  producing  that  rationale, 
is  lost.  Much  later,  the  decision  is  questioned  in  some  different  context,  and  may  be 
reversed  for  the  wrong  reasons,  and  with  damaging  results,  because  no  one  remembers 
the  situation  that  arose  before.  The  problem  leads  to  the  requirement  for  a  project 
manager’s  electronic  notebook  that  will  allow  quick  referencing  of  a  project  history 
knowledge  base  of  decision  rationale. 

6.  The  knowledge  based  system  building  tools  currently  available,  such  as  ART,  KEE,  or 
Knowledge  Craft,  etc.,  combined  with  the  Lisp  machine  environment,  provide  a  natural 
basis  for  a  prototyping  capability,  particularly  in  the  model  construction  support  tool 
arena. 

7.  Although  every  information  engineering  book  on  the  market  will  assert  that  the  busi¬ 
ness  strategy  of  a  company  should  drive  the  information  strategy,  the  process  is  rarely 
carried  out  in  practice.  In  fact,  it  can  be  argued  that  few  people  know  how  to  carry  out 
that  mapping.  Consultant  tools  that  aid  in  delivering  the  expertise  of  those  few,  even 
by  prompting  a  user  to  ask  the  right  questions,  would  be  a  boon  to  business  directed 
use  of  information. 

8.  The  USEE  project  is  highly  unusual  with  regards  to  its  plan  to  construct  development 
frameworks  for  IDS-like  implementations,  since  the  usual  case  is  not  to  plan  in  antic¬ 
ipatory  fashion  but  to  evolve  such  frameworks  out  of  repeated  experience.  One  IDS 
prototype  has  been  built.  Eventually  more  systems  of  the  type  will  follow,  and  these 
new  system  development  projects  will  have  the  framework  results  of  USEE  available  to 
them.  In  order  to  evaluate  and  improve  these  development  procedures,  relevant  data 
must  be  collected  as  new  implementations  occur.  Researchers  within  the  USEE  project 
are  people  who  will  know  what  information  needs  to  be  collected,  and  they  will  not 
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likely  be  party  directly  to  such  developments.  Thus,  one  output  of  the  USEE  effort 
should  be  a  knowledge  based  system  for  collecting  and  analyzing  information  about 
the  formulation  and  subsequent  usability  of  specific  frameworks. 

9.  A  need  that  has  been  uncovered  in  the  current  IDS  prototyping  project  at  Rockwell 
involves  use  of  a  tool  that  could  analyze  a  data  base  for  the  semantics  of  a  change 
to  the  data  base.  A  typical  scenario  occurs  when  a  change  is  made  to  a  field  in  a 
record.  That  is  an  easy  change.  The  hard  part  is  tracing  back  the  implications  of 
the  change  in  terms  of  the  underlying  information  model  semantics.  The  mapping  of 
a  logical  to  a  physical  model  (and  vice  versa),  plus  carrying  along  the  semantics  of 
the  transformation  is  a  frequently  recurring  problem  that  could  perhaps  be  addressed 
using  knowledge  based  techniques. 

10.  Configuration  management  represents  an  area  which  might  be  supported  by  knowledge 
based  techniques.  Regular  checks  on  items  such  as  identifying  files  that  have  been 
updated  are  straightforward  to  implement  with  traditional  techniques,  but  analyzing 
the  probable  implications  of  irregularities  is  a  knowledge  intensive  process. 

11.  Given  an  environment  in  which  the  design  artifacts  that  describe  a  system  are  managed 
in  an  integrated  way,  the  possibility  may  exist  for  generating  recommended  tests  that 
verify  the  code  against  the  design  specifications. 

12.  A  common  theme  in  recent  knowledge  based  work  is  one  that  addresses  the  reusabil¬ 
ity  notion  of  software  -  whether  it  be  reuse  of  code  modules,  data  structures,  or  cost 
estimation.  However,  in  every  case  that  we  have  noted,  the  key  to  reuse  is  the  deter¬ 
mination  of  a  “most  similar”  case  history.  Considerable  research  needs  to  be  done  in 
order  to  gain  an  understanding  of  what  constitutes  “relative  similarity”  in  these  cases. 
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3.4  Technology  Transfer  Requirements 

Technology  tranfer  can  be  a  key  issue  in  determining  the  success  or  the  failure  of  a  technical 
program.  For  example,  USEE  concepts  and  methods  must  be  transferred  effectively  to  a 
broad-based  user  company  goafs.  Technology  transfer  can  take  place  in  four  separate  and 
somewhat  distinct  forms.  Each  of  these  forms  of  technology  transfer  have  their  own  char¬ 
acteristics  and  requirements  in  order  to  be  effective.  The  four  widely  recognized  technology 
transfer  mechanisms  are: 

1.  Direct  Technology  Transfer, 

2.  Industry  Training, 

3.  Formal  Education,  and 

4.  Publication. 

A  brief  discussion  of  each  of  these  technology  transfer  forms  is  given  below  to  set  the 
stage  for  a  discussion  of  1ISEE  technology  transfer  requirements  in  a  subsequent  section. 

3.4.1  Direct  Technology  Transfer 

This  form  of  technology  transfer  is  represented  by  situations  in  which  artifacts  are  physically 
transferred  to  a  user.  This  situation  is  often  encountered  when  a  user  is  sold  or  is  presented 
with  a  software  package,  a  piece  of  equipment,  or  a  tool;  the  technology  is  given  to  the  user. 
Direct  technology  transfer  is  risky  and  can  be  very  ineffective  when  the  transfer  does  not 
involve  training  since  the  user  is  left  on  his  own  to  interpret  how  to  utilize  the  technology. 
It  is  doubtful  that  much  of  the  USEE  education  and/or  training  will  be  done  under  direct 
technology  transfer. 

3.4.2  Industry  Training 

The  training  of  individuals  in  USEE  concepts  and  methods  can  be  effectively  achieved  with 
the  use  of  carefully  written  training  manuals,  carefully  formulated  training  curricula  and 
training  sessions  structured  for  the  user.  When  complemented  with  up-to-date  audio-visual 
equipment  and  technology,  industry  training  sessions  delivered  in  am  instructor-lecture  format 
can  be  an  extremely  effective  and  inexpensive  method  of  transferring  technology.  Many  user 
oriented  tools  and  technologies  of  today  are  transferred  to  the  user  community  utilizing 
this  mode  of  delivery.  Industry  training  emphasizes  the  “how  to”  and  the  mechanics  of 
a  procedure  or  technology  and  not  necessarily  answering  the  question  of  why  we  solve  a 
problem  in  a  particular  way. 
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3.4.3  Formal  Education 

The  most  popular  form  of  technology  transfer  is  formal  classroom  training.  For  an  IIS  EE 
type  of  project,  formal  educational  training  usually  involves  the  development  of  a  theoretical 
base  and  a  technical  foundation  for  the  method  or  technology  being  transferred.  In  this  type 
of  technology  transfer,  a  great  deal  of  emphasis  is  placed  on  establishing  why  a  concept,  tool, 
or  procedure  is  being  used  and  how  it  was  developed  and  justified.  Due  to  the  nature  of  this 
type  of  technology  transfer,  it  usually  is  implemented  in  a  formal  classroom  environment  and 
is  most  often  offered  by  educational  institutions. 

3.4.4  Publications 

Through  journal  articles  and  technical  publications,  a  concept,  practice,  or  a  procedure  can 
be  described  or  transferred  to  a  wide  range  of  readers.  In  the  IISEE  environment,  there  are 
a  limited  number  of  publications  that  print  material  that  can  be  classified  as  educational 
or  technology  transfer  materials.  This  form  of  technology  transfer  can  be  effective  when 
certain  author-reader  combinations  axe  formed.  In  some  instances,  authors  do  not  relate  the 
material  to  be  learned  by  the  audience  effectively  to  their  readers  and  the  technology  transfer 
effectiveness  drops  off.  The  overall  technology  transfer  value  of  publications  is  difficult  to 
predict  unless  a  group  of  readers  can  be  tested  and  the  manuscript  revised  to  reflect  suggested 
changes  and  to  achieve  maximum  technology  transfer. 


3.4.5  Technology  Transfer  Requirements 

IISEE  development  and  implementation  represents  a  unique  form  of  systems  development. 
The  theories,  methodologies,  and  tools  necessary  to  achieve  an  IISEE  are  only  now  begin¬ 
ning  to  mature.  The  fact  that  there  are  number  of  significant  managerial  and  technical  skills 
which  must  be  learned,  understood,  and  applied  to  an  IISEE  project  is  becoming  quite  obvi¬ 
ous.  Education  and/or  training  support  for  the  following  areas  are  required  for  a  successful 
application  of  the  IISEE  concepts. 

•  Technical  Skills  -  An  Applications  level  understanding  of  the  following  technical  skills 
required  as  a  minimum  for  undertaking  an  IISEE  program: 

—  Systems  engineering  methodologies  (SEM)  and  systems  development  methodolo¬ 
gies  (SDM)  suitably  modified  to  support  an  IISEE 

—  IDEFO  -  Function  Modeling  Methodologies 

—  IDEF1  -  Information  Modeling  Methodologies 

—  IDEF2  -  Dynamics  Modeling  Methods 

—  Data  Base  Design  Methodologies 
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•  Managerial  Skills 

—  Project  technical  administrative  skills 
—  Project  control  skills  (time  and  resources) 

—  Knowledge  of  the  lifecycles  (technical  and  administrative) 

—  Information  Resource  Management 

We  recommend  that  due  to  the  complexities  and  uniqueness  of  USEE,  technology  transfer 
training  should  consist  of  three  distinct  modes: 

•  Concept  Training 

—  Technical  and  administrative  theories  and  practices 
—  Tools  and  the  principle  upon  which  they  are  based 

—  Methodologies  and  the  procedures  for  gaining  the  most  benefits  from  them 

—  Methods  and  the  application  framework  within  which  they  have  been  developed 
to  operate 

•  Test  Case  Analysis  of  an  actual  hands-on  experience  in  a  test-bed  environment  -  Such 
an  experience  should  involve  a  needs  analysis,  requirements  definition,  and  a  prototype 
application  of  fundamental  concepts  using  real  data  and  real  problems. 

•  Context  Analysis  -  A  detailed  investigation  using  case  study  analysis  into  the  strengths 
and  weaknesses  of  the  principles. 

It  should  be  pointed  out  that  of  these  three  approaches,  only  the  first  has  been  developed 
and  explored  to  any  large  degree.  IISEE  technology  transfer  must  take  into  account  these 
three  approaches  within  the  structure  of  each  of  the  four  technology  transfer  mechanisms 
discussed  earlier. 

An  integrated  approach  with  common  technology  threads  moving  throughout  each  tech¬ 
nology  transfer  mechanism  needs  to  be  undertaken.  In  addition,  the  technology  transfer 
mechanisms  should  be  formulated  to  take  into  account  the  various  levels  of  management  and 
personnel  that  will  be  utilizing  the  materials.  In  terms  of  direct  transfer,  a  guidebook  with 
supporting  software  should  be  developed.  The  software  can  be  developed  in  a  tutorial  format 
for  use  by  all  levels  within  the  organization  that  will  be  using  it.  For  industry  training,  slide 
sets,  scripts,  and  seminar  type  teaching  materials  can  be  developed  for  the  major  phases  of 
the  IISEE  definition  and  use.  To  satisfy  the  needs  of  the  university  community,  a  textbook 
devoted  to  the  formal  teaching  of  the  tools  and  methods  of  IISEE  needs  to  be  written.  Pub¬ 
lications  spread  the  technology  and  educate  a  far  wider  audience  than  any  other  technology 
transfer  technique.  There  are  several  methods  for  encouraging  publication  but  the  most 
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effective  would  be  to  establish  a  technical  journal  or  newsletter  devoted  to  publishing  papers 
in  the  area  of  and  USEE  framework.  A  university  is  a  very  good  host  for  such  a  journal 
or  publication  mechanism.  The  Technology  Transfer  Thrust  provided  in  Section  3.5  of  this 
report  identifies  a  set  of  projects  which  cover  these  approaches  and  mechanisms. 
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3.5  Research  Plan 

The  organization  of  the  V  ’EE  plan  follows  the  standard  format  for  program  layout  used  by 
the  Air  Force  Wright  Aer  .lautica!  Laboratories.  Figure  3.2  shows  the  basic  elements  of  such 
a  plan  and  their  relationships.  The  process  of  constructing  this  plan  involved  review  of: 

1.  The  industry  needs  and  requirements  presented  in  the  previous  sections  of  this  report. 

2.  The  results  of  inputs  from  the  TAP  members. 

3.  Discussions  with  the  Rockwell  IDS  analysis  and  development  team  experts. 

4.  Discussions  with  the  IDS  Program  office. 

5.  The  state  of  the  art  in  commercially  available  methods  and  tools. 

6.  The  literature  on  emerging  research  results  and  the  SEI  initiative. 

7.  The  research  efforts  which  were  a  part  of  this  project. 
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Figure  3.2:  USEE  Program  Plan  Elements 
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From  these  inputs  we  extracted  an  underlying  strategy  for  providing  a  comprehensive  set 
of  frameworks,  methods,  tools,  and  automated  environments  for  supporting  an  organization 
in  the  process  of  achieving  integration  through  the  use  of  the  IDS  mechanism. 

FVom  the  needs  and  the  integration  support  strategy  we  designed  a  methodology  and  tool 
development  program  which  consists  of  eight  major  technical  thrust  areas  and  specifically 
delineated  projects.  The  design  of  a  tactical  plan  of  this  type  involves  recognizing  similarities 
in  the  needs,  understanding  the  leverage  points  and  precidence  constraints  inherent  in  the 
realization  of  solutions  to  the  problems  underlying  those  needs  and  budgeting  out  an  afford¬ 
able  plan.  While  we  feel  that  the  product  which  will  emerge  from  the  following  program  has 
extensive  applicability  outside  the  IDS  framework  we  did  use  the  IDS  alignment  to  make  the 
hard  decisions  necessary  to  come  up  with  an  affordable,  achievable  program. 

The  technology  thrust  areas  chosen  by  the  coalition  for  the  plan  include: 

1.  Integration  Framework  Development 

2.  Component  Methods 

3.  System  Development  Environment 

4.  Component  Tools  for  Management 

5.  Component  Tools  for  Analysis  and  Engineering 

6.  Component  Tools  for  Software  Development 

7.  Knowledge  Based  Tools 

8.  Technology  Transfer 

The  following  sections  describe  each  thrust  area  and  the  associated  projects  in  those 
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3.5.1  Integration  Framework  Development  Thrust 

The  projects  in  this  section  are  focused  on  the  further  definition  of  the  USEE  product  struc¬ 
ture  and  the  construction  of  the  integrating  framework  component  of  that  structure  for 
several  key  application  environments.  The  frameworks  contained  in  the  plan  for  this  thrust 
are  focused  on  the  development  process  required  to  transition  an  IDS  three  schema  infor¬ 
mation  integration  architecture  into  engineering,  manufacturing,  and  logistics  operations. 
Figure  3.3  displays  the  current  definition  of  the  projects  in  this  thrust  area  and  their  relative 
timing  and  sequence.  This  thrust  area  is  also  responsible  for  the  overall  USEE  program 
coordination,  and  the  maintenance  of  external  interfaces  to  other  government  programs  (e.g. 
IDS,  SEI  etc). 

The  following  sections  provide  a  description  of  each  of  the  thrust  area  projects. 


USEE  Interproject 
Coordination 

IISEE  Syatem  Requirements 

USEE  Architecture  Design 

DoD  Prime  Contractor  ALC 
Integration  Frameworks 

IDS  First  Tier  Subcontractor 
Framework 


IDS  Second  Tier  Subcontractor 
Framework 

IDS  Large  Commercial 
Business  Framework 


IDS  Small  Business  Frmwrk. 

Information  Integrated  Syatem 
Development  Standards 


FY88  FY89  FY90  FY91  FY92  FY93  FY94  FY95 


Figure  3.3:  Framework  Development  Thrust 
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Project  Title:  IISEE  Interproject  Coordination 

Project  Goals:  The  goal  of  this  project  is  to  provide  a  co-working  /  co-development  rela¬ 
tionship  with  the  IDS  development  project  and  the  associated  IDS  implementation  projects. 
The  goal  of  this  project  also  includes  the  internal  USEE  program  coordination  (inter-project) 
and  technical  integration. 

Project  Objectives:  The  objectives  of  this  project  are  to: 

1.  Provide  bi-monthly  technical  progress  briefings  to  the  IDS  project  office  and  the  IDS 
technical  developers  on  the  results  of  IISEE  program  efforts. 

2.  Participate  in  the  tri-annual  TAG  meetings. 

3.  Organize  and  conduct  tri-annual  IISEE  technical  reviews. 

4.  Analyze  the  evolving  IDS  requirements,  designs,  and  problems  to  identify  additional 
framework,  method,  tool,  or  environment  needs. 

5.  Insure  that  those  needs  are  conveyed  to  the  appropriate  IISEE  project  as  action  items 
for  resolution. 

6.  Provide  a  central  point  for  rapid  dissemination  of  the  results  of  the  IISEE  program. 

Background:  The  purpose  of  this  project  is  to  provide  a  coordination  and  direction  setting 
effort  which  would  span  the  life  of  the  IISEE  program.  This  project  would  serve  as  a 
channel  for  methodology  and  tool  needs  from  the  IDS  development  project  to  the  IISEE 
program.  It  would  also  be  tasked  to  insure  that  the  results  of  the  development  projects  are 
quickly  assimilated  into  the  IDS  development  program.  This  project  would  be  reponsible  for 
the  configuration  management  of  the  IISEE  definition  and  design  after  the  projects  which 
define  these  items  are  completed.  Thus,  for  example,  this  project  would  maintain  /  adjust 
the  generic  versions  of  the  IDS  SDPO  and  SDP1  models  as  well  as  the  generic  integration 
framework  method  and  guidebook  as  needed. 

Approach:  The  approach  suggested  for  this  effort  is  to  establish  a  continuing  assessment 
and  configuration  management  contract.  This  program  would  serve  the  role  as  a  facilitator 
(primarily  technical)  across  the  life  of  the  IISEE  program.  Consequently  ,this  project  would 
serve  the  role  of  verification  and  validation  on  all  methods  and  tools  developed  as  a  part  of 
the  IISEE  program.  It  would  be  responsible  for  enactment  of  configuration  control  on  the 
critical  components  of  the  IISEE  as  they  are  designed.  This  organization  would  maintain  the 
library  of  technical  reports  and  software  and  would  be  responsible  for  the  dissemination  of 
those  materials.  While  the  ultimate  contracting  responsibility  would  obviously  rest  with  the 
funding  government  agencies,  this  integrating  contractor  would  serve  to  provide  a  continuity 
across  the  life  of  the  program. 

Resources:  This  project  would  require  approximately  four  manyears  per  year  of  technical 
effort  and  three  manyears  worth  of  administrative  support  effort  per  year. 
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Timing:  This  project  would  need  to  be  started  immediately  and  would  run  the  length  of 
the  USEE  program. 

Constraints:  There  are  no  special  considerations  or  constraints  on  the  establishment  of 
thi6  project. 


Project  Title:  IISEE  System  Requirements 

Project  Goals:  The  goal  of  this  project  is  to  complete  the  definition  of  the  requirements  for 
an  Integrated  Information  System  Evolution  Environment  for  IDS  implementation  support. 
Project  Objectives:  The  objectives  of  this  project  include: 

1.  Provide  a  stable  definition  of  the  function,  information  and  technology  concepts  of  the 
IDS  information  integration  strategy. 

2.  Completion  of  the  IDS  System  Implementation  Process  Function  Models  (i.e.,  a  generic 
IDS  SDPO). 

3.  Completion  of  the  IDS  System  Implementation  Process  Information  Models  (i.e.,  a 
generic  IDS  SDP1). 

4.  Definition  of  the  requirements  for  an  IISEE. 

5.  Development  of  a  conceptual  design  for  an  IISEE. 

Besides  these  technical  objectives  a  strategic  objective  of  this  project  is  to  involve  key  in¬ 
dustry,  government,  and  university  leaders  in  the  development  activities  required  to  define 
the  IISEE.  This  objective  will  help  insure  the  rapid  assimilation  of  these  techniques  into  use 
within  their  organizations. 

Background:  In  order  for  the  IISEE  to  be  successful,  its  developement  must  be  afforded 
the  same  rigorous  system  development  process  as  the  “information  systems”  which  it  will 
eventually  support.  In  this  planning  project  we  have  established  the  basic  industry  need 
categories  and  most  of  the  critical  requirements;  however,  there  is  still  a  need  to  define 
how  these  industry  needs  translate  into  a  complete  set  of  method,  tool,  framework,  and 
computerized  support  environment.  The  key  focus  of  the  modeling  of  the  system  development 
process  is  the  strategic  and  tactical  planning  activities.  The  reason  for  this  focus  is  that  an 
integrated  information  system  impacts  all  of  the  organizations  within  a  company.  The  IDS 
represents  a  business  information  strategy  and  as  such  must  be  justified  in  terms  of  existing 
strategies  and  business  plans. 

One  of  the  crucial  needs  for  IDS  assimilation  into  a  business  operation  is  effective  tech¬ 
niques  for  this  assessment  and  alignment.  The  models  and  requirements  established  in  this 
project  will  serve  as  the  basis  for  the  design  of  the  IISEE  products  (frameworks,  component 
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methods,  automated  tools,  and  development  environments).  Another  key  focus  of  this  mod¬ 
eling  activity  will  be  the  maintenance  and  support  process  since  information  integration  is 
more  a  long  term  policy  and  way  of  operation  than  a  specific  objective.  As  indicated  by  the 
first  objective  listed  above  one  of  the  important  needs  of  industry  is  for  a  stable  definition  of 
what  the  IDS  information  integration  strategy  is  and  what  the  implications  of  that  strategy 
are  for  information  engineering  within  an  organization. 

Approach:  The  approach  to  this  project  consists  of  the  establishment  of  a  coalition  of 
industry  system  developers,  Air  Force  project  engineers,  and  university  researchers  to  build  a 
composite  model  of  the  decisions,  actions,  and  activities  required  to  plan,  design,  implement, 
and  maintain  an  IDS  based  information  system.  The  project  team  will  start  with  the  results 
of  three  previous  related  projects: 

1.  The  1984  ICAM  Systems  engineering  methodology  project  (1701). 

2.  The  results  of  the  current  planning  project. 

3.  The  IDS  System  Development  Methodology  project. 

The  coalition  team  will  be  partitioned  into  four  working  groups.  The  first  group  will  focus  on 
the  business  strategy  and  planning  activities.  The  second  will  focus  on  the  technical  activities 
of  requirements,  design,  construction,  implementation,  and  maintenance.  The  third  group 
will  focus  on  the  project  management  activities.  The  fourth  group  will  focus  on  the  IDS 
concept  stabilization,  working  with  the  IDS  development  contractor,  the  IDS  program  office 
and  the  ISO  and  ANSI  working  groups. 

Resources:  The  estimated  resources  for  this  project  are  six  man  years  of  effort  which 
includes  the  costs  of  travel  and  supplies. 

Timing:  Due  to  the  amount  of  review  and  coordination  required  to  prepare  an  industry 
acceptable  requirements  statement,  it  is  recommended  that  this  project  be  scheduled  for  a 
minimum  of  16  months. 

Constraints:  All  of  the  requisite  data  for  this  task  is  available  it  should  start  immediately. 


Project  Title:  IISEE  Architecture  Design 

Project  Goals:  The  goal  of  this  project  is  to  define  the  IISEE  architecture  which  would 
delineate  the  IISEE  components  (as  illustrated  in  Section  2.4  of  this  report),  develop  the 
philosophy  of  IISEE  operation  and  use,  and  integrate  of  the  IISEE  with  the  ongoing  IDS 
development  efforts. 

Project  Objectives:  The  objective  of  this  project  is  to  take  the  conceptual  design  of 
the  IISEE  and  expand  it  into  detailed  specifications  for  each  component.  The  primary 
focus  of  this  design  effort  will  be  the  interface  specifications  which  describe  how  the  pieces 
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of  this  design  will  be  integrated  together.  This  project  would  also  be  responsible  for  the 
establishment  of  the  generic  framework  structure  and  guidebook  components  of  the  USEE. 
Background:  The  USEE  program  must  address  several  near  term  framework,  method,  and 
tool  needs.  However,  the  key  requirement  for  an  USEE  is  for  the  integration  of  all  of  these 
needs  into  a  unified  life  cycle  package.  The  detailed  design  on  the  IISEE  will  be  focused 
on  making  the  IISEE  itself  integrated.  This  effort  entails  the  dear  definition  of  all  of  the 
interfaces  between  the  actions  specified  in  the  framework  and  insuring  that  the  methods 
produce  the  data  needed  to  support  not  only  the  activities  themselves  but  also  the  decisions 
needed  to  go  from  one  activity  to  another.  This  detailing  also  requires  a  complete  human 
factors  analysis  of  the  tools  designed  to  support  the  framework  and  methods.  The  user 
interface  of  the  tools  must  be  structured  to  support  the  human  decision  process  specified  by 
the  framework  at  the  point  in  time  of  the  tool  application. 

Approach:  The  approach  recommended  for  the  detailed  design  project  is  to  use  what  has 
been  referred  to  as  a  scenario  driven  approach.  This  approach  starts  with  a  conceptual  design 
of  the  IISEE  and  (using  walk  through  by  experts)  identifies  the  detailed  specification  of  the 
form  and  function  of  the  required  interfaces.  Such  an  approach  requires  the  organization  of 
a  design  team  with  a  chief  designer  and  a  coalition  of  contributing  experts.  Central  to  this 
team  is  the  IDS  developers  who  represent  the  leading  experts  in  IDS  style  integration.  How¬ 
ever,  there  are  other  organizations  who  have  implemented  similar  three  schema  architecture 
systems  (e.g.,  the  Boeing  IISS  team)  who  would  have  to  be  identified  and  assembled  as  a 
part  of  the  design  team.  Another  critical  aspect  of  the  design  of  the  IISEE  is  how  well  the 
automated  support  tools  will  integrate  with  the  IDS  system.  Since  IDS  is  still  under  active 
development  and  expansion,  a  forum  must  be  established  for  the  IISEE  design  team  to  sub¬ 
mit  proposed  integration  mechanism  designs  to  the  IDS  design  configuration  management 
organization  for  disposition. 

Resources:  The  resources  required  for  this  task  are  estimated  at  five  manyears  for  devel¬ 
opment  and  three  manyears  for  review. 

Timing:  This  task  is  estimated  as  a  nine  to  twelve  month  activity. 

Constraints:  The  principle  constraint  on  the  initiation  of  this  task  is  the  completion  of  the 
model  portions  of  the  requirements  project  described  above. 


Project  Title:  DoD  Prime  Contractor  and  ALC  Integration  FYameworks 
Project  Goals:  The  goal  of  this  project  is  to  develop  the  IISEE  framework  component 
to  be  used  by  DoD  prime  contractors  for  strategic  and  tactical  planning,  design,  and  im¬ 
plementation  of  an  IDS  based  engineering  information  integration  system.  This  framework 
represents  the  integration  method  often  referred  to  in  the  company  needs  and  requirements 
section  of  this  report.  But  “integration”  is  not  achieved  through  the  application  of  a  single 
method  to  a  single  project.  Integration  is  achieved  by  the  focused  application  of  a  number 
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of  methods  towards  a  common,  well  defined  goal.  The  frameworks  described  in  the  following 
projects  provide  the  structure  for  application  of  this  discipline  across  a  number  of  projects 
within  the  respective  environments  which  will  conclude  in  an  integration  directed  program 
within  the  organization. 

Project  Objectives:  The  objective  of  this  project  includes  the  detailed  design,  develop¬ 
ment,  and  documentation  of  the  IISEE  framework  component  described  above.  A  second 
objective  of  this  project  would  be  the  prototype  implementation  of  IDS  in  two  prime  con¬ 
tractor  facilities  and  one  ALC  for  the  purpose  of  bootstrapping  the  development  of  the 
frameworks  in  actual  application  settings.  This  boot  strapping  activity  would  use  the  initial 
results  from  the  IDS  development  experience  and  the  initial  tools  and  methods  from  the 
parallel  development  efforts  in  other  thrusts. 

Background:  The  first  framework  to  be  developed  will  address  the  needs  and  context  of 
application  of  the  IDS  framework  in  a  large  defense  contractor  environment.  This  focus 
should  allow  for  the  most  direct  transfer  of  the  Rockwell  experience  and  will  also  cover  the 
application  to  large  AF  ALCs. 

Approach:  A  framework  is  primarily  a  methodization  of  best  practice.  To  be  successful,  it 
must  prescribe  actions  and  decisions  which  the  using  organization  can  carry  out.  Therefore  it 
represents  the  capture  of  the  experience  base  and  lessons  learned  in  one  organization  in  a  form 
usable  by  another.  Because  it  is  difficult  to  clearly  define  “what”  the  critical  knowledge  of  the 
source  organization  is  and  what  the  recipient  organization  needs,  the  approach  recommended 
involves  the  establishment  of  an  “apprentice”  program.  Through  this  program,  two  prime 
contactor  organizations  and  one  Air  Force  logistics  center  would  be  set  up  as  apprentices  to 
the  IDS  development  project  with  a  third  organization  acting  as  a  facilitator  and  recorder. 
The  apprentiship  program  would  last  through  the  implementation  of  a  prototype  IDS  within 
the  sponsored  organization’s  companies. 

Resources:  Since  the  approach  recommended  involves  the  development  of  two  IDS  imple¬ 
mentations  this  project  is  expected  to  require  on  the  order  of  30  manyears  of  effort  (although 
cost  sharing  from  the  individual  companies  could  significantly  reduce  this  figure.) 

Timing:  This  project  is  estimated  to  require  18  to  24  months  to  complete. 

Constraints:  The  primary  constraint  on  the  performance  of  this  task  is  the  availability  of 
the  IDS  development  team. 


Project  Title:  IDS  First  Tier  Subcontractor  IVamework 

Project  Goals:  The  goal  of  this  project  is  to  develop  the  IISEE  framework  component 
to  be  used  by  DoD  first  tier  subcontractors  for  strategic  and  tactical  planning,  design,  and 
implementation  of  an  IDS  based  engineering  information  integration  system. 

Project  Objectives:  The  objective  of  this  project  includes  the  detailed  design,  develop¬ 
ment,  and  documentation  of  the  IISEE  framework  component  described  above  for  application 
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to  first  tier  subcontractor  organizations.  This  project  would  also  result  in  three  prototype 
IDS  implementations  in  first  tier  subcontractor  facilities. 

Background:  The  first  tier  subcontractor  situation  is  similar  in  scope  to  the  prime  con¬ 
tractor  problem  but  generally  different  in  organizational  impact.  That  is,  the  first  tier 
subcontractor  generally  has  as  complex  an  environment  as  the  prime  contractor  in  that  the 
environment  generally  represents  a  single  division  in  the  prime  while  it  represents  the  entire 
company  of  the  first  tier  subcontractor.  Thus  the  implementation  of  an  IDS  has  much  more 
extensive  impact  on  the  total  organization. 

Approach:  It  has  been  shown  that  one  of  the  most  effective  ways  to  perform  technology 
transfer  from  the  primes  to  the  subcontractors  is  through  the  primes  themselves.  Therefore 
the  approach  suggested  is  to  match  each  of  the  primes  who  have  participated  in  the  previous 
contract  with  one  of  their  subcontractors  and  a  facilitator  to  repeat  the  process  described  for 
the  prime  of  implementing  the  IDS  in  the  subcontractor  environment.  The  IDS  developers 
would  be  involved  in  each  team  as  supporting  consultants. 

Resources:  The  estimated  resources  for  this  effort  is  25  manyears. 

Timing:  This  project  is  estimated  to  require  24  to  30  months. 

Constraints:  This  project  could  start  as  early  as  the  detailed  design  phase  of  the  prime 
contractor  framework  development  project. 


Project  Title:  IDS  Second  Tier  Subcontractor  FVamework 

Project  Goals:  The  goal  of  this  project  is  to  develop  the  IISEE  framework  component  to 
be  used  by  DoD  second  tier  subcontractors  for  strategic  and  tactical  planning,  design,  and 
implementation  of  an  IDS  based  engineering  information  integration  system. 

Project  Objectives:  The  objective  of  this  project  includes  the  detailed  design,  develop¬ 
ment,  and  documentation  of  the  IISEE  framework  component  described  above  for  applica¬ 
tion  to  first  tier  subcontractor  organizations.  This  project  will  also  result  in  three  prototype 
implementations  of  IDS  in  second  tier  subcontractor  facilities. 

Background:  The  second  tier  subcontractor  problem  of  IDS  implementation  is  similar  to 
the  first  tier  in  impact  on  the  organization  but  is  expected  to  be  of  smaller  implementation 

scale. 

Approach:  The  approach  recommended  for  this  project  is  identical  in  concept  to  that 
proposed  for  the  development  of  the  first  tier  subcontractor  framework  development.  A  set 
of  three  teams  would  be  established.  Each  team  would  consist  of  a  first  tier  subcontractor 
who  had  participated  in  the  first  tier  subcontractor  integration  framework  development  and 
one  of  his  subcontractors.  The  prime  contractor  would  be  involved  in  a  support  consulting 
role  and,  as  before,  a  facilitator  would  be  provided  on  each  team  to  record  the  development 
methods  as  they  are  defined. 

Resources:  The  estimated  resources  for  this  effort  is  20  manyears. 
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Timing:  This  project  is  estimated  to  require  24  to  30  months. 

Constraints:  This  project  could  start  as  early  as  the  detailed  design  phase  of  the  first  tier 
subcontractor  framework  development  project. 


Project  Title:  IDS  Large  Commercial  Business  IVamework 

Project  Goals:  The  goal  of  this  project  is  to  develop  the  IISEE  framework  component  to 
be  used  by  large  commercial  organizations  for  strategic  and  tactical  planning,  design,  and 
implementation  of  an  IDS  based  engineering  information  integration  system.  This  develop¬ 
ment  is  important  to  insure  that  the  commercial  and  military  sides  of  the  organization  have 
a  common  pathway  to  integration  and  control  of  their  product  data. 

Project  Objectives:  The  objective  of  this  project  is  to  establish  an  integration  framework 
effective  for  application  in  large  commercial  business  environments  and  to  demonstrate  a 
prototype  IDS  based  information  integration  mechanism  within  such  an  organization. 
Background:  The  ultimate  success  of  the  IDS  concept  will  be  measured  by  its  acceptance 
at  large  both  within  the  military  and  commercial  business  sectors.  It  is  only  with  wide  spread 
acceptance  and  support  of  the  concept  that  the  economies  of  scale  will  drive  the  technology 
to  an  acceptable  cost  and  risk  position.  This  project  is  aimed  directly  at  acceleration  of  the 
IDS  concept  by  industry  at  large  by  providing  a  customized  framework  for  commercial  use. 
This  initial  framework  will  be  targeted  towards  the  large  scale  commercial  enterprise  both 
because  of  similarity  to  the  prime  contractor  framework  and  because  the  needs  analysis  has 
indicated  that  the  business  sector  is  keenly  aware  of  the  needs  and  has  the  internal  talent 
and  resources  to  take  advantage  of  the  solution. 

Approach:  The  approach  recommended  for  this  project  is  to  team  the  facilitator,  which 
has  been  involved  in  the  previously  defined  integration  framework  developments,  with  the 
commercial  company  for  the  development  of  the  framework.  The  IDS  contractor  would  be 
involved  in  a  consulting  support  role.  The  process  would  parallel  that  used  in  the  previ¬ 
ously  described  framework  development  projects.  The  benefit  to  the  company  would  be  the 
assistance  and  partial  offset  of  costs  required  to  implement  a  prototype  information  control 
system.  The  cost  would  be  that  the  framework  developed  would  be  turned  into  the  public 
domain. 

Resources:  Because  of  the  investment  sharing  anticipated  with  the  approach  outlined 
above,  it  is  anticipated  that  the  overall  cost  of  this  project  will  be  limited  to  8  manyears. 
Timing:  This  project  is  expected  to  require  16  months. 

Constraints:  This  project  can  be  started  concurrently  with  the  first  tier  subcontractor 
framework  project. 
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Project  Title:  IDS  Small  Business  Framework 

Project  Goals:  The  goal  of  this  project  is  to  develop  the  1ISEE  framework  component 
to  be  used  by  small  business  (private  or  subtier  DoD  contractors)  for  strategic  and  tactical 
planning,  design,  and  implementation  of  an  IDS  based  engineering  information  integration 
system. 

Project  Objectives:  The  objective  of  this  project  is  to  establish  an  integration  framework 
effective  for  application  in  small  business  environments  and  to  demonstrate  a  prototype  IDS 
based  information  integration  mechanism  within  such  an  organization. 

Background:  Simply  considering  the  large  percentage  of  U.S.  industry  which  is  small  busi¬ 
ness  and  the  percentage  of  those  companies  who  produce  (or  will  produce)  DoD  goods  and 
services  justifies  the  tailoring  of  an  IDS  and  USEE  framework  to  service  this  community. 
One  advantage  of  the  small  business  application  arena  is  the  relative  lack  of  legacy  systems 
and  the  aggressive  decision  making  style  which  is  prevalent  in  this  industry  sector.  These 
factors  should  allow  for  a  streamlining  of  the  IISEE  framework  rather  than  an  elaboration. 
The  benefits  to  this  sector  in  terms  of  government  contracting  potential  combined  with  the 
inherent  increases  in  competitive  advantage  should  generate  strong  interest  in  the  technology 
if  it  can  be  put  in  a  form  accessible  to  these  organizations. 

Approach:  The  approach  to  this  project  would  require  carefull  selection  of  at  least  two 
small  businesses  with  high  visibility  in  the  national  community  and  sophisticated  enough 
operations  that  the  IDS  concepts  have  merit  in  their  environments.  These  participants  would 
be  paired  with  one  of  the  participants  in  the  first  or  second  tier  subcontractor  framework 
developments  and  a  facilitator.  The  resulting  initiatives  would  have  to  work  closely  with  the 
IDS  developers  to  determine  how  to  reduce  the  scale,  complexity  and  resource  requirements 
for  application  in  their  level  of  facilities. 

Resources:  The  resources  required  for  this  effort  axe  estimated  at  6  manyears. 

Timing:  The  time  period  required  for  this  effort  is  estimated  at  12  to  16  months. 
Constraints:  The  first  tier  subcontractor  project  should  be  completed  prior  to  the  initial¬ 
ization  of  this  effort. 


Project  Title:  Information  Integrated  System  Development  Standards 
Project  Goals:  The  goal  of  this  project  is  to  provide  a  focus  and  organizational  resource  to 
support  industry  initiatives  in  the  development  of  standards  for  the  application  of  the  IISEE. 
The  intent  of  this  project  would  be  to  accellerate  the  identification  of  areas  for  profitable 
development  of  standards  and  the  recognition  of  these  areas  by  various  standards  making 
bodies  (e.g.,  NBS,  Ansi,  Codasyl,  and  DoD  agencies). 

Project  Objectives:  The  objective  of  this  project  is  to  establish  an  information  integrated 
systems  development  standards  group  and  to  take  the  necessary  steps  to  inject  this  area  into 
the  official  standards  making  organizations. 
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Background:  In  the  long  range  implications  of  IDS  technology  on  the  military  industrial 
complex,  some  level  of  standardization  between  the  product  data  control  models  (PDCMs) 
for  those  portions  of  the  critical  life  cycle  product  data  is  needed.  The  purpose  of  this 
standards  making  activity  is  to  identify  the  lowest  level  of  standardization  for  these  structures 
which  will  allow  the  desired  data  communcations  between  these  IDS  centers. 

Approach:  The  approach  to  the  establishment  of  such  a  standards  directed  activity  should 
be  formulated  with  the  assistance  of  representatives  from  the  Codasyl  Systems  Committee, 
the  PEDES  organization,  and  the  Air  Force. 

Resources:  A  rough  estimate  of  the  resources  for  this  activity  would  be  three  manyears 
per  year  for  coordination  and  support.  It  would  be  anticipated  that  most  of  the  costs 
for  the  participating  members  would  be  absorbed  by  the  organizations  in  the  process  of 
implementing  IDS  systems. 

Timing:  This  project  is  estimated  to  require  three  years  to  develop  a  stable  working  group, 
identify  the  major  areas  for  standards  considerations,  and  start  the  transition  to  an  estab¬ 
lished  standards  making  group. 

Constraints:  This  project  should  not  start  until  the  initial  frameworks  have  been  estab¬ 
lished  and  the  IDS  prototype  implementations  are  underway. 
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3.5.2  Component  Methods  Development  Thrust 

The  projects  in  this  thrust  area  represent  the  critical  component  methods  of  the  USEE  which 
need  to  be  developed.  Figure  3.4  identifies  each  of  the  projects  currently  scoped  for  this  area 
and  illustrates  the  relative  timing  and  sequence  of  their  initiation.  This  thrust  contains  an 
emphasis  on  the  formalization  of  all  methods  to  be  used  in  the  USEE  to  insure  integratability 
of  the  methods  and  to  form  a  basis  for  evolving  a  method  engineering  discipline. 

The  following  sections  provide  a  description  of  each  of  the  thrust  area  projects. 


Ae-le  Method  Formalization 

Integrated  Data  State 
and  Proeeaa  Flow  Modeling 


Information  Syetem 
Architecture  Modeling 

Conetralnt,  Rule,  and  Domain 
Specification  Language 


Incorporation  of  Economic 
Deelefon  Analytic  Into  the 
Definition  and  Dealgn  of 
Integrated  Information  Syatema 

Total  Coat  Eatlmatlon 
of  Complex  Softwere 
Engineering  Projecta 

Economic  Evaluation  of 
Knowledge  Svatam  Technology 
Appllcatlone  t 

Information-Baaed  Syatema 

Qualitative  Coat/Benefit 
Analytic  Method 

Dealgn  Rationale 
Capture  Method 

Uaer  Interface  Modeling 

Schama  Mapping 
Dealgn  Mathoda 

IDEF  Uae  Procedure 
Definition 

Organization  Modeling/ 
Technology  Impact  Aaaeaament 

IDS  Pro|eot  Management 
Methoda 
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Figure  3.4:  Component  Method  Development  Thrust 
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Project  Title:  As-Is  Method  Formalization 

Project  Goals:  The  goal  of  this  project  is  to  provide  a  rigorous  formal  analysis  and  compar¬ 
isons  of  the  major  existing  system  planning,  analysis,  and  engineering  modeling  techniques, 
and  to  provide  a  sound  basis  on  which  to  fill  perceived  modeling  voids  with  the  extension  of 
these  techniques  and  development  of  new  techniques. 

Project  Objectives:  Phase  I  of  this  project  will  develop  the  syntactic  and  semantic  for¬ 
malization  of  the  following  information  and  data  modeling  techniques:  IDEF1-X,  N1AM 
(ENALIM),  NIAM  (Data  Model)  and  ER.  Phase  I  will  also  establish  a  standard  for  the 
formalization  of  all  future  methods  developed  under  the  USEE  program.  Phase  II  will  focus 
on  the  formalization  of  IDEFO  function  and  NIAM  process  modeling  techniques.  Phase  III 
will  focus  on  the  formalization  of  database  and  application  program  design  support  modeling 
techniques. 

Background:  Effective  analysis,  design,  and  maintenance  of  large-scale  integrated  infor¬ 
mation  systems  requires  the  use  of  flexible,  clearly  and  unambiguously  defined  information 
system  modeling  techniques  to  support  planning,  analysis  and  design  activities.  Nearly  all 
currently  existing  techniques  lack  the  sort  of  rigorous  formal  basis  that  will  permit  the  in¬ 
tegrated,  flexible  usage  that  is  required.  More  exactly,  there  is  no  mathematically  precise 
formalization  of  these  techniques  that  will  yield  precise  answers  regarding  their  consistency, 
relative  expressive  power,  and  their  intended  meanings.  This  deficiency  also  severely  ham¬ 
pers  the  teachability  of  the  techniques  and  limits  a  trainer’s  capacity  to  test  the  competence 
of  the  trainees.  Recent  developments  in  the  study  of  formal  syntax  and  semantics  have  pro¬ 
vided  all  the  tools  that  are  needed  for  the  sort  formal  basis  envisioned  here;  indeed,  this  task 
has  already  to  a  large  extent  been  carried  out  in  the  work  on  IDEFl  reported  in  Chapter 
4  of  this  report.  This  project  would  consist  of  the  further  application  of  these  tools  to  the 
syntactic  and  semantic  formalization  of  the  remaining  major  information  system  modeling 
techniques.  After  the  individual  formalizations  are  complete,  work  will  then  begin  on  formal 
comparisons  of  the  various  techniques,  extensions  of  those  techniques,  and  building  on  the 
insights  gained  from  this  work,  the  development  of  new  techniques  that  are  more  general, 
more  expressive,  and  more  flexible  still. 

Approach:  The  formalization  process  is  a  combination  of  the  following  theoretical  and 
empirical  activities,  performed  roughly  in  sequence: 

•  Examine  existing  documenation  for  the  technique  in  question  and  begin  extracting  its 
underlying  syntax  and  intended  semantics. 

•  Attempt  to  formalize  the  syntax  and  semantics.  This  involves  the  choice  of  a  lexicon, 
the  development  of  formal  grammatical  rules,  and  the  design  of  an  appropriate  math¬ 
ematical  interpretation  of  the  syntax  in  terms  of  functions,  relations,  sets,  and  other 
mathematical  objects. 

•  Identify  problems  within  the  formalization  (e.g.,  possible  misinterpretations  of  the  tech¬ 
nique),  as  well  as  apparent  problems  uncovered  within  the  technique  being  formalized 
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(e.g.,  identification  of  redundant  or  inconsistent  concepts  in  the  technique). 

•  Work  closely  with  the  original  developers  to  clear  up  misinterpretations,  to  introduce 
them  to  the  formalization  as  far  as  it  has  been  developed,  and  to  gain  their  assistance 
and  guidance  in  continuing  the  formal  development. 

•  Show  that  each  well-formed  syntactical  “model”  generated  by  the  grammar  has  an 
interpretation,  i.e.,  a  set  theoretic  representation  of  a  possible  real-world  modeling 
situation.  This  ensures  that  the  grammatical  rules  are  sound. 

•  Show  that  each  interpretation  can  be  represented  in  the  syntax.  This  ensures  that  the 
grammar  can  represent  any  possible  modeling  situation  which  it  is  designed  to  capture. 

•  Suggest  possible  extensions  to  the  modeling  technique  in  question. 

•  Begin  work  on  formal  comparisons  with  previously  formalized  modeling  techniques. 

•  Use  insights  gained  to  continue  work  on  the  more  general  modeling  technique. 

Resources:  The  resources  required  for  this  project  can  be  estimated  at  about  one  man  year 
per  method.  This  includes  time  and  travel  costs  of  the  formalization  experts,  the  method 
developer,  and  at  least  one  expert  method  practitioner. 

Timing:  Because  of  the  basis  already  established  in  previous  projects,  this  project  can  start 
immediately.  The  total  time  span  for  this  project  is  estimated  at  18  months. 

Constraints:  This  project  will  provide  the  technical  basis  for  the  development  of  the  Neu¬ 
tral  Information  Representation  Scheme  and  for  many  of  the  component  tool  developments. 
Therefore,  it  should  be  coordinated  with  those  activities  to  provide  the  proper  technical  data 
to  the  respective  development  teams. 


Project  Title:  Integrated  Data  State  and  Process  Flow  Modeling 
Project  Goals:  The  goal  of  this  project  is  to  fill  two  critical  method  voids  (data  state 
and  process  flow  modeling)  identified  in  the  course  of  this  study  as  limiting  the  capability 
to  implement  three  schema  systems,  such  as  the  IDS.  The  design  goal  of  this  project  is  to 
design  these  new  methods  from  the  formalisms  developed  for  the  IDEF  methods  so  that  they 
represent  logical  extentions  which  are  integrated  in  concept  and  practice. 

Project  Objectives:  The  objectives  of  this  project  include  the  definition,  design,  and 
development  of  the  concepts,  theory,  syntax,  procedures,  and  usage  for  data  state  modeling 
and  process  flow  modeling  in  engineering  information  systems.  The  deliverables  from  this 
project  will  be  a  three  volume  set  of  technical  documentation  for  each  method  covering 
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nespectivly  the  definition,  discipline,  and  use  of  the  method.  This  project  will  also  define  the  ' 

automation  support  requirements  for  these  methods. 

Background:  The  product  definition  data  evolves  from  the  original  requirements  in  the 

mission  definition  through  various  levels  of  engineering  maturity,  through  manufacturing, 

operations,  and  logistics  support.  Current  information  modeling  methods  are  limited  to 

the  capture  of  a  time  independent  view  of  the  composition  and  relations  of  information.  j 

While  this  is  a  critical  view  of  the  information,  to  produce  a  product  data  management 

and  control  system  which  spans  the  data  life  cycle  it  is  necessary  to  clearly  map  out  the  ' 

states  through  which  the  data  proceeds.  Along  with  the  state  definition  should  be  included 

the  representation  of  the  logic  for  state  transition  (e.g.,  the  organizational  mechanisms,  the 

preconditions,  and  the  resulting  actions  associated  with  a  transition).  The  key  to  the  design 

of  such  a  method  is  the  design  of  a  simple  approach  to  the  acquisition,  display,  management, 

and  use  of  this  complex  set  of  information. 

The  current  IDEFO  provides  an  excellent  mechanism  for  display  of  a  hierarchical  repre¬ 
sentation  of  the  activities  in  an  organization.  However,  for  the  documentation  of  the  flow  of 
major  activities  associated  with  the  product  data  life  cycle,  a  process  rather  than  functional 
view  is  required.  The  process  view  would  display  the  data  states  (rather  than  data  objects 
as  in  IDEFO)  which  are  preconditions  on  the  initiation  of  an  operation  or  process  and  the 
changes  in  those  states  caused  by  the  process. 

The  reason  for  developing  these  two  capabilities  together  is  to  insure  that  the  resulting 
two  methods  are  integrated  both  in  concept  and  application. 

Approach:  The  approach  recommended  for  this  project  involves  the  use  of  both  the  expe¬ 
rience  base  of  experienced  systems  developers  as  well  as  some  of  the  previous  research  work 
in  the  area  of  data  design  specification  languages.  The  following  steps  encompass  the  basic 
approach  which  would  be  required  for  each  method: 

1.  Refine  the  requirements  for  the  data  state  and  process  flow  methods. 

2.  Collect  sample  specifications  of  this  information  in  the  form  currently  used  by  practic¬ 
ing  system  developers. 

3.  Review  the  research  work  in  related  methods  including  DDS,  IDEF1/ES,  Petrie  Nets, 

VHDL,  ADLIB,  GMB,  and  CCS. 

4.  Work  with  the  model  formalization  project  to  formulate  the  basic  concepts  and  the¬ 
ory  of  a  data  state  and  process  flow  method  consistent  with  existing  function  and 
information  modeling  techniques. 

5.  Design  a  graphical  and  language  syntax  for  the  display  of  the  information  to  be  acquired 
using  the  methods. 

6.  Design  appropriate  forms  and  methods  for  the  acquisition  of  the  required  information 
to  populate  the  models. 
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7.  Coordinate  the  design  activities  with  the  component  tool  development  thrust. 

8.  Apply  the  developed  methods  to  a  test  case  situation  and  revise  /  refine  the  compo¬ 
nents. 

9.  Submit  the  developed  methods  for  review  by  a  group  of  information  system  developers 
(including  current  IDS  developers). 

Resources:  Previous  experience  with  method  development  has  shown  that  approximately  2 
manyears  per  method  is  required  for  the  basic  development.  Another  1  manyear  required 
to  develop  the  first  generation  management  orientation  and  technical  training  materials.  To 
support  the  testing  of  the  methods  in  an  actual  situation,  at  least  1.5  manyears  per  method 
should  be  planned. 

Timing:  This  project  will  require  at  least  18  months  to  complete  with  the  initial  method 

developments  being  completed  within  the  first  12  of  those  months 

Constraints:  This  work  could  start  within  6  months  of  the  formalization  project. 


Project  Title:  Information  System  Architecture  Modeling 

Project  Goals:  The  goal  of  this  project  is  to  develop  the  method  and  performance/cost 
analysis  techniques  to  allow  the  modeling  of  both  structural  and  physical  aspects  of  in¬ 
formation  system  architectures.  These  techniques  are  required  in  order  to  insure  that  the 
requirements  of  the  strategic  information  plans  and  logical  system  designs  will  be  realizable 
with  available  hardware,  software,  database,  and  communication  technology. 

Project  Objectives:  The  objectives  for  this  project  include: 

1.  Development  of  a  capability  to  represent  information  system  structural  and  physical 
architecture  (both  graphically  and  textually). 

2.  Development  of  a  method  for  mapping  between  the  logical  information  system  archi¬ 
tectures  and  this  implementation  view. 

3.  Development  of  a  method  for  management  of  requirement  impact  based  on  changes  to 
the  implementation  architecture. 

4.  Development  of  the  simulation  and  analytic  modeling  techniques  for  performance  pre¬ 
diction  of  the  implementation  architectures. 

Background:  The  rapid  change  in  computer  and  communications  technology  demands  a 
sophisticated  mechanism  for  easily  representing  an  implementation  architecture  and  map¬ 
ping  the  logical  system  design  onto  that  architecture.  Several  systems  such  as  AISIM  have 
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been  developed  for  the  Air  Force  which  allow  the  simulation  of  complex  computer  and  com¬ 
munication  systems  from  a  model  library  which  can  be  easily  extended  to  accommodate 
new  technology.  Such  research  products  can  be  used  as  guidelines  for  the  definition  of  what 
representation  symbology  and  language  would  be  effective  in  the  design  of  this  capability. 
Resources:  This  project  is  estimated  to  require  three  man  years  of  effort. 

Timing:  The  time  frame  for  development  of  the  definition,  discipline,  and  use  components 
of  this  method  is  estimated  at  12  months. 

Constraints:  It  is  recommended  that  the  data  state  and  process  flow  modeling  techniques 
be  structured  prior  to  the  development  of  this  capability. 


Project  Title:  Constraint,  Rule,  and  Domain  Specification  Lanaguage 
Project  Goals:  The  goal  of  this  project  is  to  develop  a  standard  language  for  relation  con¬ 
straint  specifications,  business  rule  representation,  and  attribute  value  domain  specification 
which  could  be  used  by  a  wide  variety  of  information  modeling  methods. 

Project  Objectives:  The  objectives  of  this  project  include: 

1.  Definition  of  the  language  requirements  for  the  three  languages  identified  above. 

2.  Design  of  a  syntax  and  semantics  for  each  language  which  takes  into  account  ease  of 
use  for  specification,  ease  of  interpretation,  and  ease  of  computerization. 

3.  Experimentation  with  the  application  of  the  languages  in  a  practical  setting  to  allow 
tuning  of  the  language  to  the  needs  and  capabilities  of  the  target  user  population. 

Background:  None  of  the  existing  information  modeling  methods  have  a  complete  comple¬ 
ment  of: 

1.  Relation  constraint  specification  lanaguages  for  both  procedural  and  declarative  con¬ 
straints.  (e.g.  roles,  assertions,  timing,  and  sequencing  or  general  timing  constraints 
such  as  the  currency  of  fact  relative  to  event  which  produced  fact) 

2.  Business  /  engineering  /  manufacturing  operations  rule  representation. 

3.  Attribute  value  domain  specification. 

What  is  needed  is  a  coordinated  approach  to  the  development  of  these  languages  consistent 
with  the  formal  theory  of  as  large  a  representation  of  the  current  information  modeling  meth¬ 
ods.  The  key  to  a  successful  development  of  the  required  family  of  languages  is  maintaining 
a  careful  balance  of  efficiency,  expressiveness,  and  formalism  in  the  definition  of  these  lan¬ 
guages.  Another  requirement  on  the  language  development  is  that  the  resulting  languages 
be  usable  with  (extensions  of)  existing  methods. 
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Approach:  One  fact  which  we  know  from  the  past  30  years  of  programming  and  specification 
language  design  is  that  the  requirements  of  a  language  must  be  defined  by  the  user  community 
but  the  design  of  the  language  should  be  performed  and  controlled  by  a  small,  dedicated 
team.  This  is  exactly  the  approach  which  is  recommended.  It  is  also  recommended  that  the 
approach  attempt  to  build  on  concepts  in  existing  languages  (such  as  the  NIAM  RIDLE,  OBJ, 
and  IDEF1/ES  rule  languages).  Finally,  it  is  recommended  that  the  language  development 
process  be  paired  with  application  of  the  language  in  the  framework  development  projects 
so  that  the  concepts  and  structure  can  be  tested  and  evolved  with  actual  field  use. 
Resources:  The  resources  required  for  this  project  are  estimated  to  be  on  the  order  of  six 
man  years. 

Timing:  The  development  of  the  required  languages  and  the  testing  needed  to  ensure 
usability  is  estimated  to  take  18  to  24  months. 

Constraints:  This  project  could  start  as  soon  as  the  initial  work  on  the  data  state  and 
process  flow  methods  is  complete. 


Project  Title:  Incorporation  of  Economic  Decision  Analysis  into  the  Definition 
and  Design  of  Integrated  Information  Systems 

Project  Goal:  The  goal  of  the  project  is  to  specifically  incorporate  the  modeling  and 
analysis  techniques  of  information  economics  into  the  needs  analysis  and  design  phases  of 
large  information  systems  which  require  integrated  systems  development. 

Project  Objectives:  The  specific  objective  of  this  project  is  to  establish  the  methods 
necessary  to  identify  the  payback  potential  of  information  integration  programs  within  the 
following  target  business  types: 

1.  DoD  prime  contractors 

2.  DoD  first  tier  subcontractors 

3.  DoD  second  tier  subcontractors 

4.  Air  Force  Logistics  centers 

5.  Large  commercial  organizations 

6.  Small  business 

Background:  Much  of  the  integration  that  occurs  in  the  science  of  information  development 
and  utilization  requires  that  existing  systems  be  linked  through  interfaces,  some  of  which 
have  knowledge  systems  or  expert  systems  as  their  implementing  medium.  The  remainder 
of  integrated  information  systems  involve  the  design  and  development  of  new,  broad-based 
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systems  with  complex  databases  (new  and  existing)  in  several  functions  of  the  enterprise. 
Commonly,  the  requirements  for  data  collection,  storage,  manipulation,  and  retrieval  are  not 
considered  during  the  design  phase  of  the  projects.  Thus,  the  economic  aspects  of  information 
systems  are  neglected,  and  the  users  inherit  expensive  to  operate  and  maintain  systems.  This 
project  would  concentrate  upon  the  development  of  an  automated  evaluation  system  for  data 
collection,  manipulation,  storage,  retrieval,  etc.,  to  be  utilized  during  integrated  information 
system  design.  The  deliverable  would  be  a  software  system  used  by  information  system 
designers  as  a  guide  to  data  item  selection  and  by  data  system  personnel  in  the  design  of  the 
data  collection  procedures  for  items  to  be  included  in  large  information  systems. 
Approach:  The  approach  recommended  for  this  project  involves  a  two  phase  pass  through 
the  development  life  cycle.  The  first  pass  will  produce  functional  methods  and  experimental 
software  which  can  be  used  by  the  IDS  implementation  efforts  associated  with  the  framework 
development  projects.  The  second  pass  will  build  on  the  experiences  of  these  users  and 
develop  distributable  methods  and  software. 

Resources:  This  project  is  estimated  to  require  four  manyears  of  effort  for  Phase  I  and  five 
manyears  for  Phase  II. 

Timing:  The  time  frame  for  completion  of  Phase  I  is  estimated  at  16  months.  The  duration 
of  Phase  II  would  be  determined  by  the  results  of  the  use  trials. 

Constraints:  None. 


Project  Title:  Total  Cost  Estimation  of  Complex  Software  Engineering  Projects 
Project  Goal:  The  goal  of  this  project  is  to  provide  improved  techniques  for  the  estimation 
of  costs  in  the  development  of  large  information  integrated  engineering  and  manufacturing 
systems. 

Project  Objectives:  The  project  objective  is  to  prepare,  test,  and  prototype  in  an  engi¬ 
neering  and  manufacturing  environment  a  comprehensive  cost  estimation  methodology  and 
procedure  for  large,  complex  software  development  projects. 

Background:  Much  of  the  cost  for  software  design,  development,  test,  etc.,  is  experienced  in 
support  functions  such  as  management,  planning,  information  system  integration,  resource 
allocation,  and  maintenance.  The  use  of  the  unified  life  cycle  as  a  basis  for  software  devel¬ 
opment  cost  estimation  can  lead  to  the  development  of  a  comprehensive  methodology  for 
software  planning  and  development.  Incorporation  of  the  currently  available  technical  tools 
and  procedures  for  actual  code  development  (COCOMO,  etc.)  with  the  efforts  necessary 
for  the  management  aspects  of  large  software  projects  will  give  a  much  more  realistic  total 
system  cost  estimate.  A  methodology  recently  developed  indicates  that  its  enhancement  and 
prototyping  in  a  manufacturing  environment  would  reduce  some  of  the  large  software  cost 
overruns  being  experienced. 

Approach:  The  approach  recommended  for  this  project  recognizes  the  fact  that  as  a  pro- 
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gram  evolves,  the  cost  drivers  and  benefit  categories  become  better  understood.  Therefore, 
what  is  recommended  is  the  development  of  a  set  of  cost  estimation  techniques  with  different 
characteristics  to  be  used  at  different  points  in  the  life  cycle  of  an  individual  application.  To 
make  such  a  scheme  work  requires  the  methods  developed  to  have  the  capability  to  identify 
not  only  the  estimated  costs  but  also  the  decisions  /  technology  factors  which  will  potentially 
cause  variations  and  the  anticipated  magnitude  of  these  variations.  The  method  set  must  be 
integrated  to  the  point  of  allowing  the  development  of  the  detailed  cost  /  benefit  estimations 
at  later  phases  of  the  application  development  life  cycle  off  of  the  results  of  the  previous 
estimates  with  the  additional  information. 

The  approach  taken  for  this  method  development  must  also  recognize  the  difference  in  cost 
estimation  for  application  development  and  cost  estimation  for  an  information  integration 
program.  A  separate  set  of  methods  should  be  investigated  for  the  latter,  based  on  techniques 
similar  to  those  used  to  estimate  the  cost  and  benefits  to  other  major  programs  such  as  a 
quality  improvement  program. 

Resources:  The  estimated  resource  requirement  of  this  project  is  five  man  years. 

Timing:  The  estimated  time  required  for  this  project  is  16  months. 

Constraints:  The  development  of  the  first  set  of  methods  could  proceed  immediately,  but 
the  second  set  will  require  at  least  the  first  set  of  IDS  integration  framework  developments 
to  be  complete. 


Project  Title:  Economic  Evaluation  of  Knowledge  System  Technology  Applica¬ 
tions  to  Information-Based  Systems 

Project  Goal:  The  goal  of  this  project  is  to  design  and  develop  an  economy  based  evaluation 
system  which  can  specifically  address  the  technology  of  knowledge  based  systems  when  this 
technology  is  being  considered  as  a  means  to  materially  increase  the  performance  capabilities 
of  a  currently  operating  engineering  system  or  function. 

Project  Objectives:  The  objective  of  this  project  is  to  develop  and  demonstrate  a  method 
for  assessing  the  cost  benefits  of  knowledge  based  systems  to  engineering  applications. 
Background:  All  too  often,  the  knowledge  system,  especially  in  the  form  of  an  expert 
system,  is  viewed  as  the  natural  and  most  cost  effective  means  to  improve  the  performance 
of  an  existing  system  or  to  capture  the  knowledge  present  in  an  aging,  but  essential,  system 
or  group  of  people.  Often,  however,  the  implemented  knowledge  system  is  found  to  be 
a  disappointment  because  of  its  poor  acceptance  and  utilization,  incompleteness,  or  poor 
cost  performance.  This  project  would  involve  the  incorporation  of  currently  available  cost 
and  evaluation  methods,  techniques,  and  modeling  systems  for  use  by  a  system  manager. 
Evaluation  of  the  economic  parameters  of  the  potential  knowledge  based  system  would  be 
accomplished  through  use  in  such  a  fashion  that  pertinent  cost  factors  would  be  defined, 
estimated,  and  evaluated.  This  would  force  the  decision  maker  to  carefully  examine  the 
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costs  and  benefits  of  the  anticipated  system  during  the  feasibility  study  (when  needs  and 
requirements  are  defined  and  examined),  not  once  the  design  is  in  process  or  completed. 
Resources:  The  resource  estimate  for  this  project  is  estimated  at  two  man  years. 

Timing:  The  time  requirements  for  this  project  is  ten  months. 


Project  Title:  Qualitative  Cost  /  Benefit  Analysis  Method 

Project  Goal:  The  goal  of  this  project  is  to  structure  the  use  of  qualitative  benefit  as¬ 
sessment,  analysis,  and  comparison  techniques  for  the  non-tangible  factors  in  technology 
evaluation. 

Project  Objectives:  The  project  objective  is  to  develop  and  prototype  an  analysis  process 
which  incorporates  and  quantifies  factors  which  axe  usually  considered  intangibles  with  the 
economic  productivity  factor  (described  above)  for  use  in  making  technology  based  decisions 
in  information,  automation,  etc. 

Background:  The  concept  of  system  value  is  commonly  employed  by  the  system  designer 
when  technology  decisions  must  be  made,  but  quantification  of  the  intangible  factors  is 
seldom  attempted.  Rather,  the  economic  aspects  of  the  system  project  axe  detailed  and  the 
remaining  intangible  factors,  regardless  of  their  importance,  axe  listed  in  some  form  and  not 
specifically  considered  an  integral  part  of  the  evaluation  process.  There  are  at  least  four 
major  attributes  to  be  considered  when  a  technology  improvement  decision  is  necessary: 

1.  Correspondence  with  strategic  plan 

2.  Design  capability 

3.  System  performance 

4.  Economic  performance 

There  are  several  factors  which  can  be  defined  and  tailored  for  each  of  these  attributes, 
and  the  importance  of  each  factor  can  be  determined  and  quantified  through  techniques 
such  as  the  Analytic  Hierarchy  Process  (or  others).  The  deliverable  of  such  a  project  is 
the  process,  weighting  system,  and  technique  tailored  to  technology,  especially  integrated 
information  systems,  and  a  prototype  implementation  of  the  complete  methodology.  Current 
development  of  the  analysis  process  for  a  manufacturing  environment  indicates  that  such  an 
approach  can  rapidly  put  into  perspective  the  importance  of  economic  versus  performance 
versus  strategic  technology  issues  when  decisions  vital  to  the  future  technology  level  of  an 
enterprise  are  being  made. 

Approach:  This  project  would  be  structured  as  a  two  phase  effort  with  the  first  phase 
focussed  on  the  identification  of  commonly  accepted  qualitative  factors  in  technology  eval¬ 
uation.  The  first  phase  would  also  identify  the  reasoning  methods  used  by  human  decision 
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makers  in  the  determination  of  the  relative  merits  of  these  factors.  The  second  phase  would 
focus  on  the  methodization  of  the  factor  identification  and  analysis  /  assessment  techniques. 
Resources:  The  estimated  resources  for  this  project  is  three  man  years  for  phase  I,  including 
coalition  support,  and  two  man  years  for  phase  II. 

Timing:  Phase  I  of  this  project  would  require  at  least  twelve  months.  Phase  II  could  be 
completed  in  nine  months. 

Constraints:  This  project  should  be  coordinated  with  the  previously  identified  cost  esti¬ 
mation  method  development  projects. 


Project  Title:  Design  Rationale  Capture  Method 

Project  Goals:  The  goal  of  this  project  is  to  establish  the  methods  needed  for  supporting 
the  evolution  of  an  IDS  implementation  through  the  entire  life  of  the  organization. 

Project  Objectives:  The  objective  for  this  project  is  to  develop  the  representational  ca- 
pabilty  to  capture  information  system  design  rationale  and  associate  that  rationale  with  the 
design  models  and  documentation  for  the  system. 

Background:  One  of  the  key  problems  in  the  use  of  archived  design  data  is  the  lack  of  any 
rationale  for  the  structure  function  relations  which  exist  in  the  design.  This  method  void  is 
possibly  the  largest  single  contributing  factor  to  high  maintenance  costs,  and  the  glaciation 
of  legacy  systems.  Even  with  data  dictionaries  and  complete  design  structure  definitions 
the  maintainer  of  a  system  must  still  guess  why  the  particular  structure  was  chosen  or  why 
a  particular  implementation  strategy  was  taken.  The  capture  and  transfer  of  this  design 
rationale  is  largely  by  word  of  mouth  today.  This  causes  inefficient  use  of  the  time  of  key 
personnel  and  can  cause  serious  delays  or  even  project  failures  when  team  members  leave. 
Unfort unatly  the  capture  of  this  information  is  not  a  trivial  task.  A  reasonably  sized  system 
requires  thousands  of  individual  design  and  implementation  decisions.  The  rationale  for 
each  decision  may  involve  extensive  knowledge  of  the  development  context  at  the  time  of 
the  decision.  Some  of  those  decisions  are  “obvious”  based  on  intimate  knowledge  of  the 
application  environment  and  some  are  “obvious”  based  upon  having  a  “working  knowledge” 
of  the  technology  being  applied.  Thus,  without  a  well  thought  out  method  and  a  set  of  tools 
to  support  that  method,  the  designer  is  faced  with  a  situation  in  which  he  must  attempt  to 
describe  a  complex  design  context  which  may  seem  obvious.  The  result  is  that  the  really 
valuable  information  relating  to  the  assumptions  and  tradeoffs  which  constitute  the  actual 
engineering  activity  products  is  lost.  This  issue  becomes  critical  in  considering  an  information 
integrated  system  program  such  as  an  IDS  implementation.  By  definition,  these  systems  will 
extend  through  out  the  life  of  the  corporation.  They  will  have  to  be  continuously  evolved  in 
place.  Without  such  a  method,  the  only  means  of  accomplishing  this  task  is  the  establishment 
of  a  large  organization  to  maintain  the  system. 

Approach:  The  approach  to  this  project  includes  the  following  tasks: 


i 
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1.  Apply  knowledge  engineering  methods  to  the  study  of  how  information  system  design¬ 
ers  rationalize  design  decisions. 

2.  Formalize  the  concepts  identified  in  the  study  phase  into  an  information  engineering 
rationale  annotation  method. 


3.  Develop  a  symbol  set  and  grammar  for  capturing  this  rationale. 

4.  Develop  a  mapping  technique  for  establishing  the  relation  of  this  information  to  the 
design  structure  and  specification  methods. 

5.  Validate  the  capture  and  mapping  methods  through  application  to  the  IDS  development 
project . 

A  two  phase  project  is  suggested,  with  the  first  phase  dedicated  to  the  analysis  and  formal¬ 
ization  efforts  and  the  second  phase  dedicated  to  the  methodization  and  validation  activities. 
Resources:  The  estimated  resource  requirement  for  this  project  is  15  man  years. 

Timing:  Phase  I  of  this  project  would  require  12  man  months.  Phase  II  would  require  an 
additional  9  months. 

Constraints:  This  project  must  be  closely  coordinated  with  the  knowledge  based  tool  for 
design  rationale  capture  and  the  other  method  developments. 


Project  Title:  User  Interface  iVlodeling 

Project  Goals:  The  goal  of  this  project  is  to  develop  methods  for  definition  of  user  interface 
requirements  modeling  and  presentation  style  user  interface  design. 

Project  Objectives:  The  objective  of  this  project  is  to: 

1.  Develop  a  method  for  the  acquisition  of  user  interaction  requirements. 

2.  Develop  a  design  method  for  the  definition  of  the  interaction  scenario,  external  schema, 
and  presentation  layout  to  support  the  interaction  requirements. 

3.  Develop  a  means  of  mapping  these  designs  to  the  IDS  supported  user  interface  devel¬ 
opment  utilities. 

Background:  Modeling  of  the  user  and  how  he  will  interact  with  a  system  is  a  complex 
problem  which  is  just  beginning  to  be  understood.  A  well  designed  user  interface  (UI) 
should  display  the  following  characteristics  indicative  of  the  information  to  be  captured  in  a 
UI  requirements  model: 

1.  Consistency  in  design,  including: 


Vm.  , 
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(a)  Message  system 

(b)  Layout  of  screen  design 

(c)  System  procedures 

(d)  Input  and  output  methods 

(e)  Terminology 


2.  Simplicity  and  ease  of  use,  including: 

(a)  Menu  /  Form  based 

(b)  Window-oriented 

(c)  Online  help 

(d)  User’s  guide 

(e)  Tutorial  to  guide  the  user  through  system 

Resources:  The  resources  estimated  for  the  development  of  this  method  Eire  three  man 
years. 

Timing:  The  time  required  for  this  project  is  one  year. 

Constraints:  This  project  has  no  constraining  requirements  and  may  begin  immediately. 


Project  Title:  Schema  Mapping  Methods 

Project  Goals:  The  goal  of  this  project  is  to  reduce  the  time  and  resources  required  to 
build  the  mapping  information  needed  in  the  IDS  implementation  architecture. 

Project  Objectives:  The  objective  of  this  project  is  to  develop  a  set  of  methods  to  support 
the  production  of  optimized  logic  for  the  mapping  between  external  and  conceptual  schemas 
as  well  as  between  conceptual  and  internal  schemas. 

Background:  In  order  to  make  the  EDS  concept  work  within  the  definition  of  the  internal, 
conceptual,  and  external  schemas,  one  must  also  define  the  logical  mapping  between  these 
views  of  the  data.  As  this  mapping  also  includes  the  definition  of  (and  enforcement  of)  the 
logical  and  physical  constraints  of  the  information  system  implementation,  development  of 
such  mappings  is  a  complex  task  which  can  introduce  errors  into  the  system. 

Approach:  The  approach  recommended  for  this  project  is  to  investigate  automatic  pro¬ 
gramming  research  results  (particularly  the  compiler  generator  efforts)  and  the  constraint  / 
rule  specifications  languages  being  developed  in  this  thrust  as  a  basis  for  the  development  of 
methods  for  the  mapping  specification  method. 

Resources:  The  estimated  resources  for  this  project  are  7  man  years. 

Timing:  This  project  will  require  16  to  20  months  for  completion. 
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Project  Title:  IDEF  Use  Procedure  Definition 

Project  Goals:  The  goal  of  this  project  is  to  improve  the  effectiveness  of  the  existing  IDEF 
methods  in  the  IDS  implementation  efforts. 

Project  Objectives:  The  objective  of  this  project  is  to  define  a  comprehensive  set  of 
use  procedures  for  the  IDEF  methods  which  would  cover  the  application  of  these  methods 
throughout  the  life  cycle  of  an  IDS  implemenation. 

Background:  The  models  which  result  from  the  application  of  IDEF  methods  have  been 
used  to  support: 

1.  Strategic  planning  decisions 

2.  Scoping  decisions 

3.  Cost  analysis  and  benefits  estimation 

4.  Information  system  design  analysis 

5.  Database  design  definition 

6.  Testing  and  validation 

as  well  as  many  other  activities  within  the  system  development  process.  Unfortunately  no 
description  exists  relative  to  “how”  to  use  the  models  to  accomplish  these  uses.  Therefore, 
new  practitioners  must  often  start  from  scratch  and  rediscover  for  themselves  the  procedures. 
This  fact  was  identified  as  one  of  the  major  shortfalls  of  the  IDEF  methods  by  industry. 
The  objective  of  this  project  is  to  capture  the  successful  use  of  IDEF  models  and  develop 
procedures  to  guide  future  users  of  the  methods. 

Approach:  The  approach  to  this  effort  must  start  with  the  IISEE,  IDS  SDPO,  and  IDS 
SDPl  models  to  identify  what  decisions  are  supported  by  the  IDEF  methods  in  an  IDS 
implementation.  From  this  structure  and  the  assistance  of  the  IDS  development  team,  the 
strategies  and  procedures  in  the  use  of  the  model  results  can  be  analyzed  and  documented. 
This  approach  is  iterative  and  should  extend  over  the  life  of  the  IDS  integrating  framework 
development  projects. 

Resources:  This  project  will  require  three  man  years  of  effort. 

Timing:  This  project  will  extend  over  the  lifetime  of  the  integrating  framework  development 
projects. 


Project  Title:  Organization  Modeling  /  Technology  Impact  Assessment 
Project  Goals:  The  goal  of  this  project  is  to  improve  the  capability  to  assess  the  current 
structure  and  design  of  an  organization  and  its  interaction  with  the  legacy  information  sys¬ 
tems  to  allow  the  determination  of  the  impact  of  an  IDS  implementation  in  that  environment. 
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The  purpose  of  this  project  is  to  develop  a  method  to  augment  the  tactical  planning  activity 
of  defining  a  workable  IDS  insertion  strategy  with  the  associated  technology  assimilation 
mechanisms. 

Project  Objectives:  The  objective  of  this  project  is  to  define  a  set  of  methods  for  ac¬ 
quisition  and  representation  of  the  policies,  procedures,  authorization,  decision  levels,  and 
structure  of  an  organization  and  the  relationship  between  these  facets  of  the  organization  and 
the  information  system  for  the  purpose  of  information  strategic  planning  and  the  assessment 
of  the  potential  impact  of  new  technology  on  the  enterprise.  The  objective  of  these  methods 
is  to  provide  the  data  needed  to  determine: 

1.  Is  the  IDS  capability  desirable? 

2.  What  are  the  organizational/technological  ramifications? 

3.  How  should  it  be  customized  to  fit? 

4.  In  what  order  should  the  capabilities  be  invoiced? 

5.  What  is  the  best  process  of  insertion? 

6.  How  should  the  impact  /  rate  of  resultant  change  be  controlled? 

7.  How  to  maximize  the  leverage  potential  of  the  new  technology? 

Background:  Implementation  of  IDS  technology  or  any  information  integration  mechanism 
within  an  organization  will  require  (and  result  in)  changes  to  the  organization  and  procedural 
systems  of  that  environment.  What  is  needed  is  a  method  which  allows  the  determination  of 
what  the  organizational  impact  of  information  integration  will  be  and  helps  in  both  redes:  n 
of  the  organization  and  transition  planning.  This  method  should  build  on  the  existing  IDE  ' 
methods. 

Approach:  The  approach  suggested  for  this  method  development  is  a  categorization  ap¬ 
proach  which  would  proceed  with  the  identification  of  a  frame  of  reference  and  then  the 
population  of  this  frame  of  reference  with  industry  experience.  For  example,  one  axis  of 
the  frame  of  reference  might  contain  a  variation  of  Nolan’s  stages  of  information  system 
evolution.  Another  axis  of  the  frame  of  reference  then  might  include  observable  facets  of  an 
organization  (such  as  management  style,  technology  architecture,  etc.)  In  the  cells  within 
this  matrix  would  be  observed  industry  uniformities  which  would  be  collected  by  actual  study 
of  a  set  of  industries. 

Resources:  The  estimated  resources  for  this  project  is  five  man  years  in  a  team  framework. 
Two  of  these  man  years  are  for  the  development  of  the  framework  itself.  The  other  three  is 
for  the  population  of  the  anticipated  features. 

Timing:  This  project  will  require  nine  to  twelve  months  to  develop  and  validate  the  de¬ 
scribed  methods. 
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Project  Title:  IDS  Project  Management  Methods 

Project  Goals:  The  goal  of  this  project  is  to  modify  /  extend  traditional  application 
software  project  management  methods  to  adapt  to  the  complexity  and  longevity  of  an  IDS 
implementation  within  an  organization. 

Project  Objectives:  The  objectives  of  this  effort  are  to  develop  methods  for  IDS  based 
application  project: 

1.  Planning 

2.  Task  development 

3.  Resource  allocation 

4.  Progress  tracking 

5.  Control 

Background:  Besides  the  technical  challenges  associated  with  the  implementation  of  an 
IDS  information  integration  mechanism  in  an  engineering  organization,  the  management  of 
such  a  project  presents  several  unique  challenges.  Unlike  traditional  stand-alone  application 
developments,  an  IDS  implementation  must  extend  over  organizational  boundaries  in  order 
to  be  effective.  Because  of  the  issue  of  legacy  systems,  an  IDS  implementation  will  also  ex¬ 
tend  over  many  years.  Thus,  the  management  of  such  a  project  must  take  a  long  range  view 
relative  to  technology  decisions,  cost  /  benefit  projections,  and  design  strategy  decisions.  In 
fact,  an  IDS  implementation  must  be  treated  as  the  establishment  of  an  ongoing  program, 
requiring  the  support  of  the  highest  levels  of  management  in  the  organization.  There  exists 
major  education  responsibilities  and  considerable  professional  risk  for  the  IDS  implementa¬ 
tion  management.  This  is  due  to  the  fact  that  (as  pointed  out  by  John  A.  Zachman)  “One 
can  readily  delineate  the  merits  of  the  large,  complex,  enterprise-oriented  approaches.  Such 
systems  allow  flexibility  in  managing  business  changes  and  coherency  in  the  management 
of  business  resources.  However,  there  also  is  merit  in  the  more  traditional,  smaller,  sub- 
optimal  systems  design  approach  as  well.  Such  systems  are  relatively  economical,  quickly 
implemented,  and  easier  to  design  and  manage.”  Project  management  methods  within  such 
an  environment  must  take  this  program  context  into  account. 

Approach:  The  approach  for  this  project  is  to  assemble  the  methods  currently  used  in 
stand  alone  application  development  project  management  and  (with  the  assistance  of  the 
IDS  development  and  prototype  implementation  teams)  map  these  existing  methods  onto 
the  IDS  SDPO.  FVom  this  mapping,  a  set  of  voids  and  deficiencies  in  the  existing  methods 
will  be  identified.  This  set  of  method  voids,  plus  the  experience  based  needs  from  the  IDS 
implementors,  will  then  serve  as  the  requirements  for  defining  a  modified  set  of  methods. 
Resources:  This  project  will  require  6  man  years  of  effort. 

Timing:  The  estimated  time  frame  for  this  effort  is  16  months. 

Constraints:  This  project  can  be  scheduled  to  start  shortly  after  the  initial  tactical  planning 
phases  of  the  IDS  integration  framework  for  DoD  prime  contractors  is  complete. 
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3.5.3  System  Development  Environment  Thrust 

The  projects  in  this  thrust  area  represent  the  projects  that  will  result  in  the  software  /  system 
factory  integration  environment  (refered  to  as  the  SDE)  of  the  USEE.  The  SDE  provides 
for  the  USEE  an  information  and  process  integration  mechanism  similar  to  what  the  IDS 
provides  for  the  business  environment.  The  SDE  is  the  shell  with  the  necessary  common 
utilities  to  allow  “framework”  directed  use  and  integration  of  the  component  tools  as  well 
as  the  knowledge  based  tools  in  support  of  an  IDS  implementation  and  evolution.  Figure 
3.5  identifies  each  of  the  projects  currently  scoped  for  this  area  and  illustrates  the  relative 
timing  and  sequence  of  their  initiation. 

The  following  sections  provide  a  description  of  each  of  the  thrust  area  projects. 


Development  and  Implementation 
of  a  Neutral  Information 
Representation  Scheme  (NIRS) 

Method  Integration  Standards 


SDE  Architecture  Definition 


8DE  Delivery  Architecture 
Alternatives 


Ufa  Cycle  Artifact  Manager  (LCAM) 


Reusable  Configuration  Management 
Utility  (RCMU) 

Document  Generation  Utilities 

8DE  Prototyping 

8DE  Detailed  Deaign 

SDE  Construction.  Demonstration, 
and  Support 


87  FY88  FY89  FY90  FY91  FY92  FY93  FY94  FY95 


Figure  3.5:  Computerized  Environment  Development  Thrust 
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Project  Title:  Development  and  Implementation  of  a  Neutral  Information  Rep¬ 
resentation  Scheme 

Project  Goals:  The  goal  of  this  project  is  to  develop  a  flexible  representation  mechanism 
to  support  the  integration  of  various  component  modeling  methodologies  employed  within 
an  USEE  framework. 

Project  Objectives:  The  objective  of  this  project  is  to  apply  the  formalization  results 
generated  in  the  method  formalization  project  to  the  definition,  design,  and  implementation 
of  a  neutral  information  representation  scheme  (NIRS). 

Background:  The  NIRS  is  intended  to  be  a  computer  processable  medium  for  representing 
the  results  of  application  of  the  component  methods  associated  with  an  1I3EE  framework. 
It  might  better  be  thought  of  as  a  knowledge  representation  language  that  is  so  designed  as 
to  be  able  to  represent  the  knowledge  about  both  the  “AS  IS”  system  and  the  evolving  “TO 
BE”  system.  Its  primary  purpose  is  to  support  the  movement  of  information: 

1.  Between  methods  in  a  particular  methodology  (e.g.  from  ENALIM  to  IDEF1  or  IDEFl- 
X). 

2.  Between  methods  in  different  methodologies  (e.g.  from  IDEFO  to  IDEFl-X). 

3.  Between  methods  used  in  different  phases  of  the  life  cycle  (e.g.  from  an  IDEFl-X  to  a 
Data  Structure  Diagram). 

So  envisioned,  the  NIRS  will  provide  a  modeler  with  the  capacity  to  store  information 
gathered  by  any  major  modeling  technique  in  such  a  manner  that  it  can  be  used  in  other 
stages  of  the  system  life-cycle  and  it  can  be  displayed  in  the  form  of  alternative  modeling 
techniques. 

Approach:  The  approach  suggested  for  this  representation  scheme  development  is  a  two 
phased  approach.  The  task  of  the  first  phase  is  to  analyze  the  formalization  of  the  information 
and  function  methodologies  and  design  data  structures  for  capturing  the  common  semantics 
between  the  methods  in  each  methodology.  After  a  core  set  of  these  representation  schemes 
has  been  established  for  the  common  semantic  components,  individual  specific  schemes  would 
need  to  be  put  in  place  and  translation  heuristics  developed  to  map  between  the  views  of  the 
common  information.  It  is  recommended  that  initially  the  heuristics  for  mapping  between 
IDEF1  and  ENALIM  or  IDEF1/X  be  attempted  and  as  the  mechanisms  for  implementing 
such  heuristic  strategies  evolves,  shift  the  focus  to  mapping  between  IDEFO  and  IDEF1  or 
IDEF1  and  the  process  and  data  state  modeling  methods. 

The  second  phase  of  this  project  would  evaluate  the  prototypes  developed  in  the  first 
phase  and  attempt  to  methodize  the  extension  of  the  NIRS  to  allow  for  a  structured  approach 
to  its  future  enhancement  as  new  methods  are  introduced  and  as  new  mappings  are  required. 
Resources:  The  estimated  costs  for  phase  I  of  this  project  is  5  man  years.  The  estimated 
cost  of  phase  II  is  8  man  years. 

Timing:  The  timing  for  phase  I  of  this  effort  is  12  months,  and  9  months  for  phase  II. 
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Constraints:  This  project  must  be  coordinated  with  the  method  formalization  project  and 
the  life  cycle  artifact  manager  project. 


Project  Title:  Method  Integration  Standards 

Project  Goals:  The  goal  of  this  project  is  to  establish  the  working  mechanisms  and  foun¬ 
dations  for  industry  standards  to  ensure  future  integration  of  new  methods  and  tools. 
Project  Objectives:  The  objective  of  this  project  is  to  form  an  industry  working  stan¬ 
dards  group  to  define  a  standard  for  information  exchange  between  manual  methods  and  the 
automated  tools  which  support  those  methods. 

Background:  One  of  the  critical  needs  identified  by  the  industry  survey  and  the  IDS 
development  team  is  the  lack  of  standardization  in  terminology  and  semanitics  across  the  set 
of  existing  methods  and  tools.  The  method  formalization  project  and  the  NIRS  project  will 
isolate  the  base  concepts  in  the  existing  methods.  This  project  would  be  tasked  to  establish 
usable  guidelines  for  method  and  tool  developers  to  extend  the  base  concepts  or  re-engineer 
them  in  consistent  manners.  This  project  would  also  be  tasked  with  the  establishment  of  a 
data  exchange  standard  for  moving  information  between  automated  tools. 

Approach:  This  project  has  both  a  strong  technical  and  strong  political  aspect  to  its 
implementation.  It  must  be  guided  by  the  technical  results  of  the  method  formalization 
effort  and  at  the  same  time  sensitive  to  the  commercial  tool  base.  Since  many  of  the  existing 
tools  are  marketed  as  unique  and  complete  solutions,  the  only  reasonable  way  to  establish 
data  exchange  standards  between  either  the  manual  or  automated  products  is  for  such  a 
standard  to  be  demanded  by  the  users  of  these  tools.  Thus,  the  first  phase  of  this  effort 
must  be  focused  on  organization  and  education  of  the  users  and  those  commercial  vendors 
who  can  be  convinced  of  the  long  term  benefits  to  the  industrial  and  government  community. 
Once  this  organization  is  in  place,  the  results  of  the  formalization  and  NIRS  development 
can  be  examined  as  a  basis  for  the  development  of  the  necessary  standards. 

Resources:  The  estimated  cost  for  this  project  is  6  man  years. 

Timing:  The  time  frame  for  this  effort  is  36  months. 

Constraints:  This  project  obviously  must  follow  the  lead  of  the  method  formalization 
project  and  the  NIRS  development  project.  In  order  to  remain  consistent  with  the  concept 
of  the  standards  being  user  driven,  this  project  should  also  follow  or  at  least  parallel  the 
integration  framework  development  tasks  as  these  will  develop  a  base  of  IDS  users. 


Project  Title:  System  Development  Environment  (SDE)  Architecture  Definition 

Project  Goals:  The  goal  of  this  project  is  to  establish  the  design  of  an  integrating  environ- 
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ment  to  support  the  delivery  of  a  complete  life  cycle  complement  of  automated  framework 
and  method  support  tools. 

Project  Objectives:  The  objectives  of  this  project  include: 

1.  Definition  of  the  requirements  for  an  SDE. 

2.  Development  of  a  conceptual  design  of  the  SDE. 

3.  Demonstration  of  a  prototype  SDE. 

Background:  As  illustrated  in  Section  2.4  of  this  report,  the  SDE  is  to  the  IISEE  as  the 
IDS  is  to  an  organization.  That  is,  it  represents  the  kernel  environment  for  management  and 
control  of  the  information  produced  as  life  cycle  artifacts  throughout  the  IDS  implementation 
and  evolution.  Therefore,  it  must  be  tightly  integrated  with  the  IDS  structure.  In  fact,  a 
working  prototype  of  this  kind  of  mechanism  (the  ICAM  ISDS)  was  structured  as  a  three 
schema  architecture  implementation. 

Resources:  The  estimated  resource  requirement  for  this  project  is  5  man  years. 

Timing:  This  project  can  be  completed  within  16  months. 

Constraints:  Must  follow  the  IISEE  architecture  definition. 


Project  Title:  SDE  Delivery  Architecture  Alternatives 

Project  Goals:  The  goal  of  this  project  is  to  define  a  set  of  hardware  configurations  and 
minimum  hardware  requirements  for  the  practical  delivery  of  an  SDE  support  environment 
for  the  various  IISEE  implementation  contexts. 

Project  Objectives:  The  objective  of  this  project  is  to  identify  the  minimum  hardware 
and  support  software  required  to  field  the  SDE  capabilities  in  the  various  organization  types 
for  which  frameworks  axe  being  established.  A  second  objective  of  this  project  is  to  develop  a 
method  for  determining  of  an  organization’s  hardware  requirements  for  SDE  and  an  approach 
for  evolving  from  one  level  of  SDE  implementation  to  a  higher  or  lower  level. 

Background:  The  support  requirements  which  the  hardware  and  software  components  of 
an  SDE  must  address  will  obviously  vary  based  on  the  size  of  the  organization  and  the 
information  integration  strategy  which  that  organization  is  pursuing.  Therefore,  alternate 
hardware  and  systems  architectures  must  be  defined  to  cost  effectivly  support  the  various 
levels  of  needs.  These  architectures  must  be  compatible  with  the  IDS  hardware  and  software 
support  architectures  so  that  the  SDE  can  effectively  serve  as  the  vehicle  for  feeding  those 
systems  with  new  conceptual  /  internal  /  external  schemas,  mappings,  and  interfaced  / 
integrated  applications.  A  methodology  must  be  established  for  use  by  an  organization 
to  estimate  the  level  of  support  required  so  that  the  appropriate  capitalization  can  take 
place.  However,  since  the  recommendations  of  that  methodology  will  not  likely  be  followed 
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because  management  will  attempt  to  minimize  their  risk  exposure,  an  evolution  method  must 
be  established  so  that  the  initial  architecture  can  be  expanded  or  replaced  with  minimal 
disruption  to  the  IDS  implementation  /  evolution. 

Resources:  The  resources  required  for  this  project  is  estimated  at  3  man  yews. 

Timing:  This  project  would  require  10  months  to  complete. 

Constraints:  This  project  should  follow  the  initial  SDE  architecture  definition. 


Project  Title:  Life  Cycle  Artifact  Manager  (LCAM) 

Project  Goals:  The  goal  of  this  project  is  to  develop  a  knowledge  base  management  system 
capable  of  supporting  the  intelligent  storage,  retrieval,  evolution,  and  control  of  the  infor¬ 
mation  generated  during  an  IDS  implementation  program  from  the  initial  strategic  plans  to 
the  operational  software  systems. 

Project  Objectives:  The  objective  of  this  project  is  to  implement  a  knowledge  base  man 
ager  based  on  the  NIRS  which  can  address  the  SDE  information  storage  retrieval  and  control 
requirements  to  support  the  integration  frameworks  defined  for  IDS  implementation  in  the 
industrial  and  logistics  center  environments. 

Background:  Besides  the  storage  of  common  model  data  the  SDE  must  manage  the  com¬ 
plete  complement  of  life  cycle  information  including  needs,  business  strategic  plans,  critical 
success  factors,  information  strategic  plans,  business  rules,  data  control  rules,  etc.  Some 
of  this  information  will  be  stored  in  separate  data  or  knowledge  bases  and  the  SDE  will 
only  have  to  provide  access  and  control  of  that  information.  In  other  cases,  there  will  be  a 
need  to  provide  sophisticated  knowledge  representation  support  for  information  which  will 
be  accessed  by  a  wide  range  of  method  support  tools  and  decisions  makers.  This  project  is 
responsible  for  the  development  of  a  knowledge  based  management  system  which  meets  the 
SDE  requirements.  It  is  anticipated  that  the  emerging  object  oriented  data  base  managers 
may  be  robust  enough  to  fulfill  these  needs.  It  is  also  recognized  that  the  IDS  ECS  and  DAS 
may  in  the  future  need  to  provide  a  similar  level  of  functionality,  this  offers  the  possibility 
of  joint  development  of  this  utility. 

Approach:  The  approach  for  this  development  follows  the  traditional  spiral  life  cycle  de¬ 
velopment  process  with  a  planned  three  iterations  through  the  development  cycle.  The  first 
phase  will  examine  the  direct  use  and  /  or  extension  of  existing  capabilities  such  as  the 
Ontologies  VBASE  product,  the  Carnegie  Group  Knowledge  Craft  product,  or  the  MCC 
Proteus  product.  The  second  phase  would  focus  on  the  evolution  of  an  existing  capability  or 
the  initiation  of  a  full  scale  development  of  a  new  system  based  on  the  findings  from  phase  I. 
The  last  phase  would  focus  on  the  implementation  issues  and  performance  tuning  problems 
on  the  SDE  hardware  suite  identified  in  the  previous  project. 

Resources:  If  carry  over  of  an  existing  commercial  product  can  be  achieved,  the  estimated 
cost  for  all  three  phases  of  this  project  is  10  man  years.  If  a  new  concept  must  be  implemented 
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from  scratch,  this  estimate  should  be  tripled. 

Timing:  The  time  frame  for  phase  I  is  estimated  at  10  months.  The  time  frame  for  phase 
II  is  8  months  asstiming  only  modifications  of  an  existing  knowledge  manager;  otherwise,  it 
will  require  15  months.  Phase  III  should  require  (in  either  case)  12  months. 

Constraints:  This  project  should  logically  follow  the  SDE  architecture  design  and  the  initial 
framework  development  projects. 


Project  Title:  Reusable  Configuration  Management  Utility  (RCMU) 

Project  Goals:  The  goal  of  this  project  is  to  provide  the  a  reusable  configuration  manage¬ 
ment  utility  which  can  be  applied  across  all  of  the  life  cycle  artifacts. 

Background:  A  key  component  in  the  SDE  is  a  consistent,  reusable  configuration  manage¬ 
ment  and  control  utility  which  can  be  applied  to  the  complete  spectrum  of  life  cycle  informa¬ 
tion  objects  as  dictated  by  the  integration  framework  for  a  particular  IDS  implementation 
effort.  This  implies  the  capability  to  be  programmable  with  the  particular  management  rules 
specific  to  the  object  type,  life  cycle  phase,  and  organizational  situation.  This  utility  must  be 
integrated  with  the  LCAM,  the  IDS  ECM,  EDI,  and  GDM.  It  is  anticipated  that  the  emerg¬ 
ing  object  oriented  data  base  managers  may  be  best  suited  as  a  basis  for  the  development  of 
these  needed  capabilities. 

Resources:  This  project  will  require  approximately  10  manyears  of  development  resources. 
Timing:  The  development  of  this  component  should  be  achievable  in  18  months. 
Constraints:  The  timing  of  this  project  is  set  to  start  after  the  completion  of  the  USEE 
design  project. 


Project  Title:  Document  Generation  Utilities 

Project  Goals:  The  goal  of  this  project  is  to  take  advantage  of  the  completeness  of  the 
system  description  information  contained  in  the  SDE  and  associated  component  tools  to 
reduce  the  labor  intensive  production  of  textual  documentation. 

Project  Objectives:  The  goal  of  this  project  is  to  develop  a  document  generation  sys¬ 
tem  based  on  natural  language  text  generation  techniques  to  support  the  automatic  text 
generation  from  the  contents  of  the  LCAM. 

Background:  While  the  installation  of  an  SDE  and  the  component  methods  associated 
with  the  IISEE  would  largely  eliminate  the  need  for  paper  documentation  in  the  IDS  imple¬ 
mentation  environment,  there  will  always  exist  the  need  for  production  of  the  paper  version. 
However,  the  availability  of  text  generation  techniques  will  allow  a  large  portion  of  the  man¬ 
ual  effort  required  for  the  production  of  this  data  to  be  eliminated. 
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Approach:  The  approach  recommended  for  this  project  consists  of  a  two  phase  effort. 
The  first  phase  will  be  focused  on  identification  of  the  types  of  documentation  typically 
required  and  the  modeling  of  the  information  content  of  each  type.  During  this  first  phase 
the  experience  and  techniques  used  in  the  AFHRL  Tech  Order  Authoring  system  should 
be  evaluated  and  that  products  capabilities  reviewed  as  a  base  for  extension  to  cover  these 
needs.  The  second  phase  will  focus  on  the  design  of  the  mapping  of  the  SDE  information 
to  an  intermediate  form  suitable  for  driving  a  document  generator.  The  third  phase  will 
prototype  a  document  definition  system  and  a  document  generator  driven  by  the  heuristics 
generated  for  a  particular  document  type. 

Resources:  The  resources  required  for  phase  I  of  this  project  are  estimated  at  3  man 
years.  The  resources  required  for  phase  II  of  this  project  are  estimated  at  2  man  years.  The 
resources  required  for  phase  III  of  this  project  are  estimated  at  4  man  years 
Timing:  The  total  time  for  all  phases  of  this  project  is  24  months. 

Constraints:  This  project  must  at  least  follow  the  LCAM  prototyping  phase. 


Project  Title:  SDE  Prototyping 

Project  Goals:  The  goal  of  this  project  is  to  introduce  the  SDE  concept  as  early  as  possible 
into  the  IDS  development  and  implemenation  projects  for  evaluation  and  experimental  use. 
Project  Objectives:  The  objective  of  this  project  is  to  develop  a  series  of  prototype  SDE 
implementations  which  would  be  provided  to  the  IDS  development  team  and  the  integration 
framework  efforts  for  evaluation  and  testing  to  evolve  the  functionality  and  user  interface 
requirements  for  the  IDS. 

Background:  Consistent  with  the  information  engineering  approach  followed  in  the  IDS 
development,  it  is  necessary  to  prototype  the  SDE  to  enable  use  and  feedback  from  the 
system  development  community.  It  is  recommended  that  the  first  prototypes  be  constructed 
on  top  of  the  integrated  programming  environment  of  a  Lisp  machine.  In  the  latter  stages 
the  kernel  functions  will  have  to  be  ported  to  more  traditional  architectures  unless  the  Lisp 
chip  technology  emerges  as  co-processors  on  traditional  application  delivery  machines. 
Approach:  The  approach  to  this  project  is  to  produce  a  prototype  SDE  every  year  for  three 
years.  The  first  prototypes  will  serve  as  development  platforms  for  the  SDE  components  in  a 
boot  strapping  fashion.  At  least  one  version  of  each  of  the  component  tools  will  be  developed 
in  these  prototype  environments.  These  prototypes  will  also  be  made  available  to  the  IDS 
developers  and  IDS  implementation  efforts  under  the  integration  framework  development 
activities. 

Resources:  Each  SDE  prototype  will  require  at  least  8  man  years  of  development  effort. 
An  additional  3  man  years  per  year  is  planned  in  the  last  two  years  for  user  support  of  the 
previously  distributed  systems. 

Timing:  This  project  is  expected  to  last  for  36  months. 
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Constraints:  The  development  of  the  first  prototype  can  be  scheduled  to  proceed  immedi¬ 
ately  following  the  requirements  definition  phase  of  the  SDE  architecture  project. 


Project  Title:  SDE  Detailed  Design 

Project  Goals:  The  goal  of  this  project  is  to  establish  the  specifications  of  a  production 
SDE. 

Project  Objectives:  The  objective  of  this  project  is  to  develop  the  detailed  design  for  the 
SDE  based  on  the  results  of  the  requirements  and  prototyping  efforts. 

Background:  This  project  includes  an  implicit  recommendation  that  the  specification  of 
the  production  version  of  the  SDE  be  developed  in  conjunction  with  the  SDE  prototyping 
efforts  but  as  a  separate  project  to  allow  the  design  team  to  make  maximum  use  of  the  proto¬ 
type  experience  while  maintaining  the  necessary  independence  to  make  structural  deviations 
required  for  a  delivery  system. 

Approach:  This  project  is  scheduled  to  start  in  the  middle  of  the  second  SDE  prototyping 
effort.  At  this  point,  it  will  be  able  to  borrow  concepts  from  not  only  the  SDE  prototype 
but  at  least  two  versions  of  the  IDS  and  the  ICAM  IISS  implemenation.  It  would  employ 
the  detailed  design  methods  established  in  the  generic  USEE  framework  definition. 
Resources:  The  planned  resources  for  this  project  are  3  man  years  of  effort. 

Timing:  This  project  is  expected  to  take  12  to  15  months. 


Project  Title:  SDE  Construction,  Demonstration  and  Support 

Project  Goals:  The  goal  of  this  project  is  to  complete  the  development  of  a  production 
version  of  the  SDE  and  to  demonstrate  the  effectiveness  of  that  product. 

Project  Objectives:  The  first  objective  of  this  project  is  to  realize  a  production  version 
of  the  SDE  and  to  implement  that  capability  in  an  IDS  implementation  environment.  The 
second  objective  of  this  project  is  to  support  the  integration  of  the  evolving  component 
tools.  The  third  objective  is  to  demonstrate  the  effectiveness  of  the  SDE  to  support  an 
IISEE  integration  framework  in  an  IDS  implementation  program.  Finally,  this  project  is  to 
provide  continued  support  for  the  users  of  SDE  over  the  remaining  life  of  the  IISEE  program. 
Approach:  A  suggested  approach  to  this  project  would  involve  three  phases  of  effort.  The 
first  phase  would  be  responsible  for  the  construction,  integration  and  testing  of  the  SDE 
kernel  and  the  core  components  under  development  in  this  thrust.  The  second  phase  would 
support  the  integration  of  the  individual  method  support  tools  and  the  establishment  and 
support  of  a  user  test  community.  The  third  phase  would  combine  maintenance  distribution 
and  continued  enhancement  of  the  proven  configuration. 
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Resources:  The  realization  phase  of  this  project  is  estimated  at  20  man  years.  The  initial 
implementation  and  modification  effort  is  estimated  at  15  man  years.  The  maintenance  / 
enhancement  and  support  of  the  SDE  for  the  remaining  years  of  the  IISEE  will  require  at 
least  5  man  years  per  year. 

Timing:  The  construction  of  the  SDE  will  require  16  months,  the  initial  component  tool 
integration  and  test  site  implementation  will  overlap  the  construction  effort  by  four  months 
and  require  an  additional  10  months.  The  support  activities  are  planned  for  the  remainder 
of  the  life  of  the  IISEE. 

Constraints:  Project  starts  after  detailed  design  of  SDE. 
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3.5.4  Component  Tools  for  Information  Evolution  Management 
Thrust 

The  projects  in  this  thrust  area  represent  the  critical  component  tool  developments  necces- 
aary  to  support  managers  in  realistic  IDS  implementation  environments.  This  thrust  also 
includes  the  standards  development  necessary  to  make  use  of  commercially  available  tools 
in  the  IISEE  software  /  system  factory  in  support  of  project  management  activities.  Figure 
3.6  identifies  each  of  the  projects  currently  scoped  for  this  area  and  illustrates  the  relative 
timing  and  sequence  of  their  initiation. 

The  following  sections  provide  a  description  of  each  of  the  thrust  area  projects. 


Strategic  Planning  Support 

Tactic el  Plan  Generation 
Support 

Integration  of  Project  Planning 
and  Cost  Tracking  Toola  into 
the  SDE 

Compute  Aida  for  Group 
Process  Enhancement 


Figure  3.6:  Component  Tools  for  Project  Managers  Thrust 
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Project  Title:  Strategic  Planning  Support 

Project  Goals:  The  goal  of  this  project  is  to  provide  managers  with  the  necessary  auto¬ 
mated  support  to  effectively  carry  out  an  IDS  strategic  planning  task. 

Project  Objectives:  The  goal  of  this  project  is  to  establish  an  integrated  set  of  information 
collection,  analysis,  and  aggregation  tools  for  support  of  the  strategic  planning  process.  The 
integration  must  allow  continued  management  of  the  strategic  plans  and  assessment  of  change 
impact  over  time. 

Background:  Strategic  planning  tools  are  required  to  allow  the  accumulation  of  individual 
organizational  goals  and  the  summarization  of  these  goals  at  the  overall  corporate  level.  A 
capability  is  needed  to  manage  the  mapping  of  these  goals  to  a  set  of  critical  success  factors  for 
each  organizational  unit.  An  indexing  capability  is  needed  to  allow  identification  of  common 
success  factors  and  goals  across  organizations  and  a  means  of  mapping  information  system 
strategies  to  these  common  directions.  Since  the  integration  program  will  extend  over  a  long 
period  of  time,  there  must  be  support  for  the  determination  of  the  change  impact  of  goals 
and  success  factors  on  the  information  system  strategy  and  the  information  system  design 
decisions.  This  implies  the  need  for  these  strategic  planning  tools  to  be  integrated  with  the 
LCAM  and  for  the  system  design  support  tools  to  allow  for  the  definition  of  “influences”, 
“causes”,  and  “dependency”  relations  between  the  information  strategies  and  the  system 
design  structure  and  composition. 

Approach:  The  recommended  approach  to  this  tool  development  is  to  use  a  rapid  pro¬ 
totyping  method  building  off  of  a  robust  knowledge  base  management  system  such  as  the 
Knowledge  Craft  CRL  product  from  Carnegie  Group  or  the  NoteCards  system  from  XE¬ 
ROX.  These  tools  support  the  dynamic  creation  of  complex  relation  types,  easy  prototyping 
of  sophisticated  user  interfaces,  and  the  ability  to  formulate  complex  queries  against  the  in¬ 
formation  in  the  knowledge  bases.  The  development  process  could  then  proceed  in  much  the 
same  fashion  as  a  knowledge  engineering  process  with  the  rapid  development  of  prototype 
tools  and  the  evaluation  of  these  tools  by  experienced  strategic  planners. 

Resources:  This  project  is  estimated  to  require  six  manyears  of  development  effort. 
Timing:  The  time  period  for  the  prototyping  effort  of  this  project  is  estimated  at  three  to 
six  months.  The  refinement  of  the  prototype  into  a  fieldable  system  will  require  an  additional 
twelve  months. 

Constraints:  This  project  should  follow  the  intial  phases  of  the  prime  contractor  integration 
framework  development  activities. 


Project  Title:  Tbctical  Plan  Generation  Support 

Project  Goals:  The  goal  of  this  project  is  to  provide  support  to  the  project  manager  in 
an  IDS  implementation  program  for  dealing  with  the  complexity  of  the  tactical  planning 
problem. 
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Project  Objectives:  The  objective  of  this  project  is  to  develop  a  tactical  planning  ca¬ 
pability  to  assist  managers  in  the  development  of  the  project  plans  necessary  for  an  IDS 
implementation  program. 

Background:  Tactical  planning  is  essentially  a  complex  design  process.  It  requires  the 
design  of  a  set  of  activities  and  a  time  allocation  of  resources  to  accomplish  the  strategic 
goals.  Existing  PERT  and  CPM  techniques  are  useful  analysis  tools  but  lack  the  design 
support  capabilities  to  cost  effectively  generate  a  complex  IDS  implementation  plan.  What 
is  needed  is  a  set  of  tools  which  are  integrated  with  the  strategic  planning,  requirements 
analysis,  and  architecture  design  tools.  This  set  of  tools  must  support  the  partitioning 
of  the  implementation  architecture  development  into  affordabe  development  projects.  The 
tools  must  also  support  the  project  planning  for  the  transition  of  the  legacy  systems  into 
the  integrated  environment.  The  tools  must  have  the  capabilities  to  be  integrated  with 
traditional  program  planning  tools  so  that  the  results  of  the  tactical  planning  can  be  easily 
transitioned  into  the  individual  project  management  environments  and  so  that  changes  to 
the  tactical  plan  can  be  evaluated  for  the  impact  on  ongoing  projects. 

Resources:  The  resources  required  for  this  project  are  estimated  at  eight  man  years. 
Timing:  The  time  period  for  this  project  is  estimated  at  eighteen  months. 

Constraints:  This  project  should  not  be  started  until  the  prototyping  portion  of  the  strate¬ 
gic  planning  project  is  complete. 


Project  Title:  Integration  of  Project  Planning  and  Cost  Tracking  Tools  into  the 
SDE 

Project  Goals:  The  goal  of  this  project  is  to  provide  the  basic  working  managers  tool  set 
integrated  with  SDE. 

Project  Objectives:  The  objective  of  this  project  is  to  develop  a  traditional  set  of  project 
planning,  budgeting,  scheduling,  and  cost  trauung  tools  as  an  integrated  set  of  components 
within  the  SDE. 

Approach:  The  recommended  approach  to  this  project  is  summarized  in  the  following  tasks: 

1.  Identify  existing  project  planning,  budgeting,  scheduling,  and  cost  tracking  automated 
tools. 

2.  Define  the  requirements  for  integration  of  those  tools  within  the  USEE  environment. 

3.  Develop  the  necessary  software  for  the  integration  of  these  tools  into  the  SDE. 

Resources:  The  resources  required  for  this  project  are  estimated  at  4  man  years. 

Timing:  The  analysis  and  development  time  required  for  this  project  is  12  months. 
Constraints:  This  project  should  not  start  until  the  IDS  applications  project  management 
methods  are  developed. 
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Project  Title:  Computer  Aids  for  Group  Process  Enhancement 
Project  Goals:  The  goal  of  this  project  is  to  develop  the  methods  and  multimedia  tools 
necessary  to  enhance  the  efficiency  of  component  modeling  methods  which  require  the  inter¬ 
action  of  luge  groups  of  domain  personnel. 

Project  Objectives: 

Background:  All  of  the  existing  methods  for  strategic,  tactical  and  operational  planning, 
analysis,  and  design  require  the  acquisition  of  data  from  a  large  number  of  individuals,  group 
review,  and  group  consensus  of  the  method  results.  Development  of  tools  to  structure  that 
group  process  or  change  the  way  the  individuals  can  be  brought  together  to  reach  consensus 
descisions  will  radically  reduce  the  costs  of  performing  the  required  analysis  and  modeling. 
Resources:  The  estimated  resource  requirement  for  this  project  is  10  man  years. 

Timing:  The  time  period  required  for  the  development  and  evaluation  of  these  methods  is 
12  months. 

Constraints:  None. 
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3.5.5  Component  Tools  for  Analysis  and  Engineering  Thrust 

The  projects  in  this  thrust  area  represent  the  critical  component  tools  development  needed  to 
support  the  analysis  and  engineering  activities  necessary  for  an  IDS  implementation  and  evo¬ 
lution.  Figure  3.7  identifies  each  of  the  projects  currently  scoped  for  this  area  and  illustrates 
the  relative  timing  and  sequence  of  their  initiation. 

The  following  sections  provide  a  description  of  each  of  the  thrust  area  projects. 


Modeling  Tool  Development 
Utilities 

Legacy  Software 
Analysis  Tools 

Seed  Support  for 
Commercial  Tool  Integration 

Integrated  Data  State  and 
Process  Flow  Modeling  Tool 

Database  Design  Alternative 
Generation  and  Analysis  Tool 

Systems  Architecture  Modeling 
Support 

Classifier  &  Cluster  Analysis 
Utility 

Conceptual,  Internal,  and 
External  Schema  Designer 

Micro  Based  Data 
Collection  Support 


Figure  3.7:  Component 


Tools  for  Analysis  and  Engineering  Thrust 


I  t,t  O  l.i  I.u.t  J.  A' 


CHAPTER  3.  PLAN  FOR  DEVELOPMENT  OF  STRUCTURED  FRAMEWORKS  120 


Project  Title:  Modeling  Tool  Development  Utilities 

Project  Goals:  The  goal  of  this  project  is  to  reduce  the  time  and  cost  necessary  to  build 
modeling  support  tools  for  a  manual  method. 

Project  Objectives:  The  objective  of  this  project  is  to  develop  a  set  of  modeling  support 
tool  generation  utilities  to  allow  the  development  of  interactive  computer  based  modeling 
support  utilities  (such  as  an  AutoIDEFO)  with  less  than  six  manweeks  of  effort. 
Background:  The  large  number  of  different  methods  with  alternative  display  presentation 
forms  must  be  employed  to  successfully  carry  out  an  IDS  implementation  program  warrants 
the  development  of  a  flexible  utility  for  the  development  of  computer  aided  modeling  support 
tools. 

Resources:  The  resources  required  for  this  tool  generation  capability  development  are 
estimated  at  6  man  years. 

Timing:  The  time  required  to  carry  out  this  development  is  estimated  at  12  months. 
Constraints:  There  are  no  specific  constraints  on  the  initiation  of  this  task. 


Project  Title:  Legacy  Software  Analysis  Tools 

Project  Goals:  The  goal  of  this  project  is  to  provide  a  comprehensive  set  of  software 
analysis  tools  for  assisting  in  the  evaluation  of  the  exiting  software  base  during  an  IDS 
implementation. 

Project  Objectives:  The  objectives  of  this  project  include: 


1.  Development  of  software  audit  tools  to  extract  the  data  constraints  enforced  by  a  set 
of  modules  in  a  database  application  system. 


2.  Modification  of  existing  “call  tree”  generators  for  population  of  process  models  of  a 
system. 


3.  Development  of  data  definition  trace  utilities  to  map  out  compiled  and  included  data 
structures. 


4.  Development  of  data  base  schema  processors  for  generation  of  partial  conceptual  schema 
structures  from  the  existing  internal  schemas. 


Background:  By  far  the  most  expensive  part  of  the  “AS-IS”  analysis  required  to  implement 
an  IDS  is  the  definition  of  the  conceptual  view  of  the  legacy  information  systems.  Often  the 
original  developers  of  these  systems  are  no  longer  available  or  have  long  forgotten  the  actual 
entities  managed  and  the  business  rules  enforced  by  these  systems.  Most  of  the  effort  at 
the  definition  of  these  systems  has  focused  on  the  modeling  of  the  external  user  view  of  the 
system  and  then  the  patching  of  a  demonstratable  interface  via  complex  mapping  rules. 
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Approach:  Since  these  analysis  tools  will  be  highly  environment  dependent,  it  is  recom¬ 
mended  that  an  initial  development  effort  focus  on  the  development  of  specific  tools  for  a 
specific  application  (e.g.  IDS  implementation  at  Rockwell).  The  second  phase  of  the  pro¬ 
gram  could  use  these  initially  hard  coded  tools  as  a  basis  for  generalization  to  support  the 
development  of  a  configurable  set  of  utilities  for  building  specific  analyzers. 

Resources:  The  resources  required  to  develop  these  analysis  tools  is  estimated  at  15  man 
years.  The  resources  required  to  build  the  generalized  utilities  is  20  man  years. 

Timing:  The  overall  time  period  for  this  project  is  estimated  at  28  months. 

Constraints:  This  project  could  start  immediately. 


Project  Title:  Seed  Support  for  Commercial  Tool  Integration 

Project  Goals:  The  goal  of  this  project  is  to  accellerate  the  integration  of  commercial  tools 
into  the  SDE  framework. 

Project  Objectives:  The  objective  of  this  project  is  to  provide  seed  monies  for  the  modi¬ 
fication  of  existing  commercial  tools  to  conform  to  the  tool  data  exchange  standards  and  the 
SDE  framework. 

Background:  Due  to  the  currently  limited  market  for  information  integration  engineering 
tools,  many  of  the  existing  commercial  tools  are  supplied  by  small  business  concerns  who 
do  not  necessarily  have  the  ready  resources  or  the  developer  base  to  make  the  modifications 
necessary  to  commit  to  a  new  standard.  In  order  to  accellerate  the  acceptance  of  the  tool 
data  exchange  standards,  it  is  recommended  that  seed  monies  and  assistance  be  provided  for 
the  updating  of  the  product  documentation  with  a  formalization  section  and  the  modification 
of  the  tools  to  provide  access  to  a  model  in  the  standard  format. 

Resources:  The  resources  required  for  this  project  would  vary  depending  upon  the  com¬ 
plexity  of  the  tool. 

Timing:  This  project  is  planned  for  a  three  year  time  frame. 

Constraints:  This  project  could  start  towards  the  end  of  the  formalization  effort  and 
roughly  one  year  into  the  standardization  effort. 


Project  Title:  Integrated  Data  State  and  Process  Flow  Modeling  Tool 
Project  Goals:  The  goal  of  this  project  is  to  develop  an  automated  support  tool  for  the 
data  state  and  process  flow  methods  developed  under  the  Component  Method  thrust. 
Project  Objectives:  The  objective  of  this  project  is  to  produce  near  term  automated 
support  for  the  application  of  the  data  state  and  process  flow  modeling  method  which  are 
integrated  with  an  IDEFO  and  IDEFl  modeling  capability. 
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Approach:  The  approach  recommended  for  this  project  is  to  utilize  the  Lisp  machine 
processing  environment  to  develop  a  near  term  automated  model  development  support  en¬ 
vironment  for  IDEFO,  IDEFl,  Data  State,  and  Process  Flow  modeling. 

Resources:  The  resources  required  for  this  tool  developement  is  three  man  years. 

Timing:  This  project  would  require  6  months  to  complete. 

Constraints:  This  project  would  provide  a  much  needed  modeling  support  capability  and 
should  be  started  immediately. 


Project  Title:  Database  Design  Alternative  Generation  and  Analysis  Tool 
Project  Goals:  The  goal  of  this  project  is  to  provide  an  analytic  basis  for  evaluating  the 
impact  on  dr ‘abase  design  of  the  desired  data  control  policies  of  an  organization. 

Project  Objectives:  The  objective  of  this  project  is  to  develop  a  capability  to  simulate 
various  database  design  concepts  based  on  the  information  model  semantics,  the  data  state 
transitions,  the  process  flow  characteristics  to  predict  the  performance  impact  of  the  trans¬ 
action  rates,  and  integrity  rules  implied  by  these  models  and  a  particular  database  design 
approach. 

Resources:  The  resources  for  this  tool  development  is  estimated  at  7  man  years. 

Timing:  This  project  will  require  16  months  to  complete. 

Constraints:  The  above  referenced  component  methods  development  should  be  complete 
prior  to  the  initiation  of  this  task. 


Project  Title:  Systems  Architecture  Modeling  Support 

Project  Goals:  The  goal  of  this  project  is  to  develop  a  computer  aided  information  system 
architecture  design  support  tool. 

Project  Objectives:  This  tool  must  provide  support  for: 

1.  Easy  configuration  of  system  architectures  from  standard  components. 

2.  Stochastic  as  well  as  simulation  analysis. 

3.  Ability  to  capture  the  design  rationale  as  well  as  the  design  configuration. 

4.  Modeling  of  all  system  interfaces. 

5.  Display  of  “AS  IS”  and  “TO  BE”  architectures. 
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This  tool  must  implement  the  information  systems  architecture  specification  method  devel¬ 
oped  under  the  component  method  thrust. 

Approach:  The  first  phase  of  this  effort  will  be  focused  on  the  development  of  a  modeling 
support  tool  for  the  information  system  architecture  definition  method  developed  under  the 
component  method  thrust.  The  second  phase  of  this  effort  will  add  to  that  capability  support 
for  design  analysis  via  simulation  and  stochastic  modeling. 

Resources:  This  project  is  estimated  to  require  5  man  years  of  development  effort. 
Timing:  The  development  of  the  modeling  support  should  require  6  months,  the  analysis 
capability  will  require  an  additional  12  months. 

Constraints:  The  availability  of  the  formalized  version  of  the  information  system  architec¬ 
ture  specification  language. 


Project  Title:  Classifier  and  Cluster  Analysis  Utility 

Project  Goals:  The  goal  of  this  project  is  to  provide  a  set  of  utilities  which  can  be  applied 
to  various  life  cycle  artifacts  to  allow  similarity  measures  and  family  groupings  to  support 
planning,  analysis,  and  design  decision  making. 

Project  Objectives:  The  objective  of  this  project  is  to  develop  a  set  of  tools  for  factor 
analysis,  characteristic  based  cluster  generation,  and  fuzzy  association  to  support  planning, 
analysis,  and  design  decision  makeing. 

Background:  The  ICAM  projects  in  Group  technology  and  Integrated  Decision  Support 
Systems  developed  a  number  of  utilities  for  cluster  analysis,  fuzzy  associations,  and  charac¬ 
teristic  based  family  generation.  This  project  would  build  on  that  base  to  provide  a  similar 
set  of  tools  to  be  used  in  the  needs  analysis  and  project  planning  activities  within  the  IISEE. 
Resources:  This  project  would  require  3  man  years  of  development  effort. 

Timing:  The  time  required  for  development  of  these  utilities  is  9  months. 

Constraints:  This  project  should  be  coordinated  with  the  strategic  and  tactical  planning 
methods  developments,  and  the  IDEF  use  procedure  developments. 


Project  Title:  Conceptual,  Internal,  and  External  Schema  Designer 

Project  Goals:  The  goal  of  this  project  is  to  reduce  the  time  and  cost  associated  with 

definition  of  the  requisite  definitions  for  an  IDS  implementation. 

Project  Objectives:  The  objective  of  this  project  is  to  develop  a  design  support  tool  for 
the  translation  of  information  models,  data  state  models,  and  process  models  into  conceptual 
schemas  for  the  population  of  the  IDS  PCDM.  This  also  includes  support  for  the  development 
of  the  translations  (or  mapping  specifications)  from  the  external  schemas  to  the  conceptual 
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schemas  and  from  the  conceptual  schemas  to  the  internal  schemas.  Finally  this  project  is 
tasked  with  the  development  of  a  design  support  environment  which  would  support  the  de¬ 
velopment  of  user  interface  presentations  and  external  schemas  from  the  information  models, 
process  flow  models,  and  user  models. 

Background:  Essentially  this  project  is  a  project  in  design  automation  for  IDS  implementor 
support.  There  is  a  related  project  in  the  knowlege  based  systems  thrust  which  addresses 
the  addition  of  intelligent  support  to  the  design  automation  task.  This  project  is  focused  on 
use  of  traditional  methods  at  least  at  the  time  of  this  conceptualization.  It  may  turn  out 
that  heuristic  based  techniques  are  required  for  the  various  mappings  involved. 

Approach:  The  suggested  approach  for  this  task  is  to  set  up  a  two  phase  project.  The  first 
phase  would  be  a  prototyping  phase  with  the  focus  of  working  with  the  IDS  developers  and 
iteratively  evolving  acceptable  solutions  to  the  design  support  problem.  The  second  phase 
of  the  project  would  be  focused  on  a  wider  evaluation  of  the  tools  by  IDS  implementers  and 
then,  based  on  the  total  set  of  requirements,  the  development  of  a  production  tool  set. 
Resources:  The  resources  estimated  for  this  task  are  7  man  years  for  phase  I  and  10  man 
years  for  phase  II. 

Timing:  Phase  I  can  be  complete  in  10  months.  Phase  II  will  require  an  additional  12 
months. 

Constraints:  This  project  should  follow  the  schema  mapping  method  development  project. 


Project  Title:  Micro  Based  Data  Collection  Support 

Project  Goals:  The  goal  of  this  project  is  to  develop  a  suite  of  micro  based  information 
acquisition  support  utilities  for  support  of  the  various  methods  required  for  IDS  implemen¬ 
tation. 

Project  Objectives:  The  objective  of  this  project  is  to  develop  micro  based  support  for 
collection,  organization,  management,  and  limited  analysis  and  display  of  information  needed 
to  build  IDEFO,  IDEF1,  Data  State,  and  Process  Flow  modeling  techniques. 

Background:  A  large  amount  of  the  effort  involved  in  strategic  planning  for  an  information 
integrated  program  within  an  organization  is  the  “field”  work  associated  with  information 
acquisition  and  manipulation.  These  proposed  tools  would  provide  a  capability  to  utilize 
portable  automation  to  improve  the  efficiency  and  productivity  of  that  process. 

Resources:  The  resources  required  for  this  effort  are  estimated  at  3  man  years. 

Timing:  This  effort  can  be  completed  in  8  man  months. 

Constraints:  The  data  state  and  process  flow  method  disciplines  must  be  complete  prior 
to  the  initiation  of  this  task. 
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3.5.6  Component  Tools  for  Software  Development  Thrust 

The  projects  in  this  thrust  area  represent  the  critical  component  tool  developments  and 
standards  developments  necessary  to  use  commercially  available  tools  in  the  IISEE  software 
/  system  factory  to  support  the  software  development  process.  Figure  3.8  identifies  each  of 
the  projects  currently  scoped  for  this  area  and  illustrates  the  relative  timing  and  sequence 
of  their  initiation. 


Software  Development  Support 
Tool  Requirements 

Rapid  Prototyping  of  IDS 
Applications 

Utilities  for  Support  of 
Software  Reusablity 

Semantic  Mapping  from 
Information  Models  to 
Database  Systems 
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Figure  3.8:  Component  Tools  for  Software  Development  Thrust 
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Project  Title:  Software  Development  Support  Tool  Requirements 

Project  Goals:  The  goal  of  this  project  is  to  identify  the  productivity  leverage  areas  for 
automated  support  to  IDS  application  developers. 

Project  Objectives:  The  objective  of  this  project  is  to  define  the  needs  and  requirements 
of  the  software  programmer  for  specialized  programming,  integration,  and  testing  tools  to 
support  IDS  implementation. 

Background:  The  experience  base  on  which  this  IISEE  program  plan  was  structured  was 
heavily  influenced  by  planning  and  analysis  needs.  IDS  represents  a  new  programming 
paradigm  in  the  engineering,  manufacturing,  and  logistics  computing  worlds.  The  experience 
which  will  be  accumulated  over  the  next  several  years  will  identify  a  number  of  low  cost  tools 
which  offer  a  high  productivity  return  for  the  programming  staff  charged  with  building  and 
maintaining  applications  in  this  environment. 

Approach:  A  traditional  needs  analysis  and  requirements  definition  process  and  a  tactical 
plan  development  are  the  basic  tasks  required  in  the  approach  to  this  project. 

Resources:  The  resources  required  for  this  project  are  2  man  years. 

Timing:  This  project  should  be  completed  in  8  months. 

Constraints:  This  project  should  be  initiated  during  the  initial  IDS  prototype  implemen¬ 
tation  efforts. 


Project  Title:  Rapid  Prototyping  of  IDS  Applications 

Project  Goals:  The  goal  of  this  project  is  to  develop  the  capability  to  take  advantage  of  the 
inherent  system  definition  available  in  the  IDS  to  allow  rapid  prototyping  of  new  engineering 
or  manufacturing  applications. 

Project  Objectives:  The  objective  of  this  project  would  be  to  develop  application  gen¬ 
eration  software  for  the  complete  generation  of  IDS  applications  from  the  user,  function, 
information,  and  process  flow  model  specifications. 

Background:  Fourth  generation  development  languages  and  data  base  prototyping  lan¬ 
guages  have  been  developed  which  produce  reasonably  sophisticated  applications  from  less 
complete  specifications  than  the  IDS  conceptual  data  model.  Therefore  it  is  anticipated  that 
with  moderate  effort,  IDS  implementations  could  support  extensive  prototype  generation 
capability. 

Resources:  The  estimated  resources  for  this  development  are  10  man  years. 

Timing:  This  project  should  be  achievable  in  18  months. 

Constraints:  This  development  activity  could  start  immediately. 
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Project  Title:  Utilities  for  Support  of  Software  Reusablity 

Project  Goals:  The  goal  of  this  project  is  to  develop  the  capability  to  support  reuse 
of  existing  IDS  schema  definitions,  schema  mappings,  user  interface  software,  or  complete 
applications. 

Project  Objectives:  The  objective  of  this  project  is  to  develop  the  analysis  tools  and 
dictionary  classification  mechanisms  required  to  augment  the  current  IDS  definitional  capa¬ 
bilities  in  order  to  support  extensive  reusability  of  the  application  and  software  base. 
Background:  Software  reusability  has  been  a  long  sought  goal  in  the  software  engineer¬ 
ing  community.  However  most  existing  systems  suffer  from  extremely  sparse  definitional 
basis  outside  of  the  source  code  itself.  The  greatest  success  with  software  reusability  has 
been  achieved  in  the  object  oriented  programming  environment  (e.g.  Flavors,  SmallTalk,  and 
Loops).  This  reusability  was  achieved  without  such  dictionary  classification  mechanisms  by 
providing  mechanisms  for  easily  combining  the  behavior  of  many  small,  specialized  objects. 
This  particular  option  can  in  a  certain  sense  be  duplicated  in  the  IDS  environment.  How¬ 
ever,  the  legacy  software  problem  limits  its  applicability.  The  result  is  that  a  combination 
of  classification  methods  and  encapsulation  methods  will  have  to  be  explored. 

Resources:  The  estimated  resources  for  this  project  are  12  man  years. 

Timing:  The  time  requirement  for  this  project  is  28  months. 

Constraints:  This  project  should  be  delayed  until  the  design  rationale  capture  method  is 
firmly  underway. 


Project  Title:  Semantic  Mapping  from  Information  Models  to  Database  Systems 
Project  Goals:  The  goal  of  this  project  is  to  improve  the  ability  of  the  analyst  to  interpret 
large  amounts  of  unfamiliar  database  system  code. 

Project  Objectives:  The  objective  of  this  project  is  to  build  an  analysis  tool  for  the 
database  programmer  to  allow  the  interpretation  of  database  schema  structures  in  terms  of 
the  original  semantic  models  from  which  these  schemas  were  designed. 

Background:  With  the  availability  of  design  rationale  encoding  and  the  information  in 
the  conceptual  schema,  all  of  the  information  is  available  for  the  construction  of  a  tool  to 
reverse  interpret  a  set  of  database  structures  in  terms  of  the  original  semantic  models.  This 
interpretation  to  a  programmer  unfamiliar  with  a  large  database  design  can  be  difficult  or 
impossible  to  extract  since  the  mapping  of  the  original  meaning  of  a  coherent  portion  of  the 
original  code  may  be  dispersed  throughout  a  data  base  structure.  What  may  have  seemed 
like  minor  syntactic  modifications  of  entity  or  attribute  labels  by  the  designer  can  cause 
significant  confusion  to  the  new  programmer.  In  future  versions  of  this  tool,  knowledge 
based  heuristic  techniques  could  be  employed  to  detect  inconsistencies  in  the  use  of  labels 
(multiple  meanings  for  the  label  “part-indenture,”  for  example). 

Resources:  This  project  will  require  4  man  years  to  develop  the  initial  prototype  semantic 
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mapping  tool  and  an  additional  8  man  years  for  a  full  production  utility. 

Timing:  The  first  prototype  will  require  10  months  to  construct.  The  production  utility 
would  require  an  additional  18  months. 

Constraints:  The  feasibility  of  this  tool  is  dependent  on  the  existence  of  the  design  rationale 
capture  method  and  the  capabilty  of  the  LCAM  to  represent  that  information. 
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3.5.7  Knowledge  Based  Tool  Development  Thrust 

The  projects  in  this  thrust  area  represent  the  opportunities  for  the  application  of  knowledge 
based  systems  techniques  to  the  IDS  system  development  /  application  arena.  Figure  3.9 
identifies  each  of  the  projects  currently  scoped  for  this  area  and  illustrates  the  relative  timing 
and  sequence  of  their  initiation. 

The  following  sections  provide  a  description  of  each  of  the  thrust  area  projects. 


Utilities  for  Construction  of 
Intelligent  Modeling  Support 
Environments 


Expert  System  Based 
Guidebook 


ICAI  Development  Utilities 


Information  System  Description 
Capture  Environment 


Project  Manager'a  Assistant 


Natural  Language  Interfacea 
to  SDE 


Intelligent  Knowledge 
Acquisition  Support 


IDS  Designer  Assistant 
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Figure  3.9:  Knowledge  Based  Tool  Development  Thrust 
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Project  Title:  Utilities  for  Construction  of  Intelligent  Modeling  Support  Envi¬ 
ronments 

Project  Goals:  The  goal  of  this  project  is  to  put  in  place  the  utilities  required  to  build  the 
knowledge  based  systems  described  in  this  thrust  area. 

Project  Objectives:  The  objectives  of  this  project  are  to: 

1.  Define  the  requirements  for  intelligent  modeling  support  environment  construction  util¬ 
ities. 

2.  Design  the  set  of  utilities  to  meet  these  requirements. 

3.  Construction  of  the  set  of  utilities. 

4.  Rehosting  of  the  utilities  on  the  various  hardware  types  in  the  SDE. 

Background:  The  utilities  for  constructing  modeling  support  environments  provided  on 
modern  Lisp  machines  provide  an  order  of  magnitude  decrease  in  the  development  time  and 
cost  for  these  systems  over  conventional  hardware  environments.  Most  of  this  productivity 
increase  is  due  to: 

1.  The  integrated  set  of  editing,  compilation,  debugging,  and  user  interface  construction 
utilities  provided. 

2.  The  object  oriented  programming  environment  which  maximizes  the  reusability  of  the 
primitives  provided. 

3.  The  hardware  implementation  of  the  base  symbolic  manipulation  capabilities  needed 
to  efficiently  support  rapid  prototyping  based  on  software  reuse  concepts. 

The  task  ahead  of  this  project  is  to  construct  the  additional  utilities  required  to  achieve 
the  same  level  of  productivity  in  the  process  of  adding  intelligence  to  the  modeling  support 
environments.  The  research  associated  with  this  planning  effort  has  identified  the  need  for 
the  following  utilities: 

i..  Knowledge  base  management  utilities. 

2.  Reusable  reasoning  mechanisms  including: 

(a)  Constraint  propagation  mechanisms. 

(b)  Efficient  rule  production  engines. 

(c)  Resolution  refutation  mechanisms. 


3.  Libraries  of  frequently  used  life  cycle  artifact  objects  and  relation  representations. 
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Approach:  The  approach  to  this  project  will  follow  the  “Spiral”  model  of  software  devel¬ 
opment.  This  model  calls  for  the  production  of  an  increasingly  complex  system  by  iterative 
application  of  the  traditional  life  cycle.  The  planned  approach  of  this  project  calls  for  two 
iterations  through  that  spiral. 

Resources:  The  resources  required  for  this  project  are  estimated  at  ten  manyears. 
Timing:  The  approximate  duration  of  this  task  is  15  months. 

Constraints:  There  are  no  project  dependency  constraints  on  this  utility  development 
project. 


Project  Title:  Expert  System  Based  Guidebook 

Project  Goals:  The  goal  of  this  project  is  to  develop  the  capability  to  quickly  and  efficiently 
orient  a  new  user  to  the  appropriate  framework  for  his  environment  and  to  make  minor  tuning 
to  that  framework. 

Project  Objectives:  The  objective  of  this  project  is  to  produce  an  expert  system  to 
assist  the  potential  user  of  an  USEE  in  the  selection  of  an  appropriate  framework  and  the 
configuration  of  that  framework  for  his  particular  needs. 

Background:  The  rr  :or  classes  of  organizational  contexts  which  are  of  first  interest  in  the 
development  of  integration  frameworks  have  been  provided  in  the  framework  development 
thrust.  However,  even  within  one  of  these  major  classes,  there  is  a  considerable  amount 
of  tuning  which  could  be  beneficially  applied  to  a  framework  to  account  for  the  individual 
site  situation.  Initially,  this  tuning  will  have  to  be  done  by  hand.  The  USEE  guidebook 
will  contain  the  decision  procedures  for  getting  a  user  to  the  correct  framework  and  the 
individual  framework  guidebook  will  contain  the  procedure  for  tuning  that  framework  for 
the  individual  needs.  It  is  anticipated  that  even  with  this  guidance  problems  due  to  lack  of 
understanding  of  the  guidebook  decision  logic  will  arise.  This  project  proposes  to  develop  a 
knowledge  based  implementation  of  those  guidebooks  so  that  the  knowledge  of  the  original 
developers  of  the  procedures  can  be  more  directly  brought  to  bear  on  the  situation. 
Approach:  The  approach  recommended  for  this  project  consists  of  a  two  phase  effort.  The 
first  phase  would  be  focused  on  the  required  knowledge  engineering  and  design  work  required 
for  the  development  of  a  proof  of  concept  prototype.  The  second  phase  would  be  focused 
on  the  completion  of  the  knowledge  engineering  and  the  traditional  software  development 
required  to  produce  a  fieldable  expert  system  which  could  be  distributed  along  with  the 
USEE  product. 

Resources:  This  project  is  estimated  to  require  7  man  years  of  effort. 

Timing:  This  project  can  be  completed  within  16  months. 

Constraints:  This  project  is  constained  to  follow  at  least  the  establishment  of  two  of  the 
integration  frameworks  described  in  the  Integrated  FVamework  Thrust  area. 
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Project  Title:  ICAI  Development  Utilities 

Project  Goals:  The  goal  of  this  project  is  to  utilize  knowledge  based  systems  techniques 
to  assist  in  the  transfer  of  the  knowledge  of  method  experts  to  the  novice  participants  on  a 
project. 

Project  Objectives:  The  objective  of  this  project  is  to  develop  a  set  of  utilities  required 
to  support  the  development  of  intelligent  tutoring  systems  to  increase  the  rate  of  technology 
transfer  of  the  USEE  product  into  production  use. 

Background:  One  of  the  largest  impediments  to  the  widespread  implementation  and  use 
of  IDS  is  the  amount  of  training  required  of  the  organizations  desiring  to  employ  the  tech¬ 
nology.  Intelligent  computer  aided  instruction  or  tutoring  systems  can  help  to  overcome 
this  obstacle.  However,  ICAI  systems  have  been  more  difficult  and  expensive  to  build  than 
expert  systems  themselves.  Establishment  of  model  driven  ICAI  development  utilities  which 
allow  the  assisted  construction  of  ICAI  applications  from  student  models,  domain  models, 
and  performance  measurement  structures  could  reduce  the  time  and  effort  for  construction 
of  these  systems  by  half. 

Approach:  The  approach  to  the  development  of  these  utilities  will  follow  the  “Spiral”  model 
of  software  development.  This  model  calls  for  the  production  of  an  ever  increasingly  complex 
system  by  iterative  application  of  the  traditional  life  cycle.  The  planned  approach  of  this 
project  calls  for  three  iterations  through  that  spiral.  The  first  iteration  through  this  spiral 
would  be  coordinated  with  one  of  the  tutorial  developments  for  a  component  method.  This 
phase  would  build  an  ICAI  application  for  this  tutorial.  The  second  phase  of  the  project 
would  use  the  experience  gained  in  the  first  iteration  combined  with  a  requirements  study 
of  the  other  tutorial  projects  to  identify  and  construct  a  set  of  generic  utilities.  The  third 
interation  would  again  construct  an  ICAI  application  with  these  utilities  and  enhance  the 
utilities  as  required. 

Resources:  The  resources  estimated  for  this  project  are  15  man  years. 

Timing:  Phase  I  of  this  project  should  require  eight  months.  Phase  II  of  this  project  will 
require  14  months  and  Phase  III  will  require  four  months. 

Constraints:  The  development  of  these  baseline  utilities  do  not  directly  depend  on  previous 
project  results.  However,  this  project  should  be  closely  coordinated  with  the  Intelligent 
Modeling  Support  Utilities  project  described  above. 


Project  Title:  Information  System  Description  Capture  Environment 
Project  Goals:  The  goal  of  this  project  is  to  tightly  couple  the  system  analysis  with  the 
actual  engineering  environment  in  order  to  improve  the  quality  of  IDS  applications. 
Project  Objectives:  The  objective  of  this  project  is  to  establish  the  capability  to  automat¬ 
ically  generate  system  analysis  models  from  descriptions  of  the  engineering  or  manufacturing 
domain. 
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Background:  The  nature  of  system  analysis  models  is  that  they  are  filtered  through  the 
interpretation  of  the  modeler.  While  the  users  are  typically  called  upon  to  review  and  validate 
the  models,  they  often  overlook  the  implications  of  the  structures  or  assertions  w’hich  are 
made  in  those  models.  Often  the  shear  volume  of  information  which  the  analyst  must  process 
causes  him  to  gloss  over  key  points  in  the  system  description. 

Approach: 

Resources:  This  project  will  require  10  man  years  of  development  for  the  capture  portion 
of  the  system  and  an  additional  8  man  years  for  the  model  design  generator. 

Timing:  The  total  project  time  frame  for  this  effort  is  24  months. 

Constraints:  This  project  could  start  immediately. 


Project  Title:  Project  Manager’s  Assistant 

Project  Goals:  The  goal  of  this  project  is  to  apply  knowledge  based  techniques  to  the 
creation  of  a  capability  to  leverage  the  skills  of  the  IDS  implementation  and  application 
project  managers. 

Project  Objectives:  The  objective  of  this  project  is  to  develop  a  knowledge  based  set  of 
tools  for  assisting  in  the  planning,  design  decision  making  and  control  tasks  of  the  program 
and  project  managers  in  an  IDS  implementation  environment. 

Background:  One  of  the  most  complex  tasks  for  the  project  manager  in  a  large  development 
program  like  the  IDS  is  the  management  of  the  design  decisions  as  they  evolve  through  time. 
Particularly  if  he  must  manage  several  projects  simultaneously.  Also  keeping  track  of  the 
assumptions  on  which  project  plans  were  built  and  logically  analyzing  changes  against  this 
assumption  base.  This  project  is  aimed  at  the  development  of  a  knowledge  based  assistant. 
This  system  would  be  capable  of  recording  the  plan  assumptions  an  performing  logical  “what 
if”  analysis  against  that  assumptive  base.  This  system  would  also  provide  for  the  recording  of 
management  design  decisions  and  the  rationale  behind  those  decisions  similar  to  the  designers 
assistant  described  later  in  this  thrust  area. 

Approach:  The  approach  recommended  for  this  project  consists  of  a  two  phase  effort.  The 
first  phase  would  be  focused  on  the  required  knowledge  engineering  and  design  work  required 
for  the  development  of  a  proof  of  concept  prototype.  The  second  phase  would  be  focused 
on  the  completion  of  the  knowledge  engineering  and  the  traditional  software  development 
required  to  produce  a  fieldable  project  assistant  system. 

Resources:  This  project  will  require  12  man  years  of  development  resources. 

Timing:  A  prototype  version  of  this  tool  could  be  completed  in  8  months.  A  robust  version 
integrated  into  the  SDE  tool  suite  would  require  and  additional  10  months. 

Constraints:  Work  could  be  started  on  this  tool  as  soon  as  the  management  method 
development  activities  were  stabilized. 
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Project  Title:  Natural  Language  Interfaces  to  SDE 

Project  Goals:  The  goal  of  this  project  is  to  provide  a  development  capability  to  the  IDS 
application  developer  to  incorporate  restricted  natual  language  capabilities  into  IDS  interface 
designs. 

Project  Objectives:  The  goal  of  this  project  is  to  develop  a  reusable  set  of  utilities  for 
constructing  simple  command,  query,  and  text  understanding  natural  language. 
Background:  The  information  delivery  capabilities  of  IDS  have  the  potential  to  far  outstrip 
what  the  application  developer  has  the  ability  to  forsee  or  the  capability  to  support  prompt 
and  menu  interfaces.  Restricted  natural  language  (if  the  user  is  properly  trained  in  its  use) 
offers  the  capabilty  to  take  full  advantage  of  the  inherent  IDS  information  potential.  However, 
without  the  proper  development  tools  and  utilities,  the  construction  of  a  simple  command 
completion,  DWIM  (do  what  I  mean)  or  other  restricted  natural  language  interface  difficult 
and  expensive.  Tools  (such  as  the  Carnegie  Group  Language  Craft)  have  be  shown  to  allow 
the  construction  of  relatively  sophisticated  natural  language  like  interfaces  in  short  periods 
of  time.  In  this  project  we  are  suggesting  the  development  of  a  set  of  utilities  which  would 
be  fully  integrated  into  the  user  interface  development  package  on  IDS  and  would  support 
the  development  of  these  types  of  systems. 

Approach:  The  first  task  associated  with  this  project  is  to  examine  the  potential  appli¬ 
cation  areas  for  restricted  natual  language  interfaces  in  an  IDS  environment.  It  would  be 
recommended  to  construct  some  “clay  model”  systems  with  the  available  prototyping  tools 
to  generate  ideas  and  feedback  from  both  the  developer  community  and  the  user  commu¬ 
nity.  The  approach  recommended  for  this  development  task  requires  an  upfront  choice  of  a 
linguistic  paradigm  (lexical  functional  grammar,  generative  transformational  grammar,  case 
frame  etc.)  based  on  the  results  of  the  requirements  and  prototyping  activities  and  the  avail¬ 
ability  of  accessible  software  for  the  paradigm.  Once  this  decision  is  made  then  the  design  of 
the  structure  and  components  of  the  utilities  can  be  established  and  the  development  of  the 
necessary  software  performed.  One  of  the  design  goals  of  the  system  would  be  to  incorporate 
an  expert  system  design  support  tool  as  an  element  to  assist  system  designers  who  are  not 
familiar  with  the  underlying  language  theory. 

Resources:  The  resources  required  for  this  task  are  estimated  to  be  8  man  years. 

Timing:  This  project  will  require  24  months  to  complete. 

Constraints:  This  project  could  start  immediately. 


Project  Title:  Intelligent  Knowledge  Acquisition  Support 

Project  Goals:  The  goals  of  this  project  are  to  improve  the  quality  and  reduce  the  cost  of 
information  model  development  and  use. 

Project  Objectives:  The  objective  of  this  project  is  to  develop  automated  knowledge  based 
support  for  the  construction  of  information  models  and  the  analysis  of  information  models 
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for  completeness,  consistency,  and  correctness. 

Background:  In  the  exploratory  research  efforts  associated  with  this  project,  we  discovered 
that  the  vocabulary  and  language  structure  used  to  describe  business  rules  in  the  engineering 
and  manufacturing  domains  was  suprisingly  restricted.  In  three  separate  information  models 
built  by  three  different  coalitions  over  a  period  of  almost  seven  years,  there  were  fewer  than  70 
linguistic  verb  case  structures  used.  This  kind  of  regularity  in  the  structure  and  use  of  natural 
language  in  a  specific  domain  is  usually  indicative  of  the  ability  to  develop  sophisticated  user 
interfaces  which  can  process  a  large  percentage  of  natural  language  statements  about  the 
domain.  In  the  particular  case  in  point,  it  is  possible  to  construct  a  system  which  would 
accept  natural  language  statments  about  the  business  rules  of  the  organization  and  produce 
information  models  in  various  forms  (e.g.  IDEF1,  ENALIM,  ER,  IDEF1/X).  It  would  also 
be  possible  to  construct  textual  summarization  of  the  implications  (implicit  assertions)  of 
an  information  model  to  assist  in  the  validation  process.  Limited  capabilities  of  this  latter 
sort  already  exist  as  simple  paraphrasing  devices.  However,  these  concepts  could  be  greatly 
expanded  to  include  textual  summarizations  and  interactive  question  and  answer  discourse. 
Resources:  The  estimated  resources  for  this  project  are  estimated  at  6  man  years. 
Timing:  This  project  is  scheduled  for  18  months. 

Constraints:  This  project  can  start  immediately. 


Project  Title:  IDS  Designer/Data  Administrator  Assistant 

Project  Goals:  The  goal  of  this  project  is  to  develop  a  capability  to  provide  design  eval¬ 
uation,  documentation,  and  rationale  capture  to  the  IDS  application  designer  and  data 
administrator. 

Project  Objectives:  The  objective  of  this  project  is  to  provide  knowledge  based  support 
to  the  development  of  the  IDS  implementation  and  design  rationale  capture  method. 
Background:  A  comprehensive  design  support  environment  must  provide: 


1.  Control  and  manipulation  of  the  design  process  state. 


2.  Support  based  on  the  goal  structure  of  the  particular  design  process  instance. 


3.  Record  of  the  design  decisions  and  the  assumptions  of  those  decisions. 


4.  Rationale  for  the  design  decisions. 


5.  Support  for  the  use  of  predictive  analytic  models. 


6.  Support  for  the  use  of  qualitative  evaluation  tests. 
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With  the  definitional  basis  of  the  LCAM  and  the  IDS  conceptual  schema,  the  foundation 
exists  for  providing  intelligent  design  support  to  the  IDS  implementation  administrator  and 
to  the  IDS  application  developer  in  all  of  the  above  listed  areas. 

Resources:  The  resources  required  for  this  project  are  12  man  years  for  prototype  and 
validation  of  that  prototype  by  the  IDS  design  experts. 

Timing:  This  project  should  take  six  months  for  the  initial  prototype  and  15  months  of 
expansion  and  validation  to  achieve  a  usable  system. 

Constraints:  This  project  should  be  delayed  until  the  completion  of  the  initial  IDS  imple¬ 
mentations. 
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3.5.8  Technology  Transfer  Thrust 

The  projects  in  this  thrust  area  represent  the  technology  transfer  efforts  in  support  of  the 
USEE  which  need  to  be  undertaken.  It  should  be  noted  that  the  real  objective  of  this  thrust 
is  to  transfer  understanding.  Figure  3.10  identifies  each  of  the  projects  currently  scoped  for 
this  area  and  illustrates  the  relative  timing  and  sequence  of  their  initiation.  The  following 
sections  provide  a  description  of  each  of  the  thrust  area  projects. 


Component  Method  Tutorials 

Component  Tool  Tutorials 

System  Development 
Environment  (SDE)  Tutorials 

Integration  Framework 
Tutorials 

IISEE  Handbook  Series 
IISEE  Conferences 

Managing  an  IDS 
Implementation  Project 


Figure  3.10:  Technology  Transfer  Thrust 
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Project  Title:  Component  Method  Tutorials 

Project  Goals:  The  purpose  of  this  project  will  be  to  develop  a  tutorial  type  of  educational 
package  which  will  provide  an  overview  of  the  component  methods  available  for  systems  mod¬ 
eling,  procedures  definition,  systems  design  logic,  system  architecture  definition,  and  other 
pertinent  design  areas.  As  a  secondary  goal,  the  overview  will  be  supported  by  individual 
educational  modules  which  outline  in  detail  the  theory,  technical  qualities,  and  implementa¬ 
tion  strategies  for  each  of  the  individual  tools.  The  long  term  targets  will  be  to  build  a  large 
volume  of  educational  modules  for  technology  transfer  that  will  be  linked  together  through 
an  overview  or  tutorial  package  that  introduces  the  methods  to  the  student. 

Project  Objectives:  The  objective  of  the  proposed  project  will  be  to  establish  a  foundation 
and  a  structure  for  a  framework  overview  module  and  for  the  modules  that  detail  each 
individual  method.  The  initial  thrust  will  be  to  define  a  flexible  structure  that  can  be  added 
to  as  the  frameworks  and  new  methods  evolve.  The  initial  deliverables  will  include  a  highly 
structured  overview  module  and  three  detailed  modules  illustrating  how  a  total  method 
package  will  fit  together. 

Background:  To  date,  training  and/or  technology  transfer  packages  have  been  devoted  to 
the  education  of  individuals  in  the  use  of  a  particular  tool  (i.e.,  1DEF0,  IDEF,  group  tech¬ 
nology).  Very  little  effort  has  been  put  into  the  establishment  of  a  comprehensive  package 
of  technology  transfer  modules  that  are  logically  tied  together  through  an  overview  mod¬ 
ule.  In  the  area  of  component  methods,  it  is  especially  important  that  system  designers 
be  provided  with  an  understanding  of  available  methods,  how  they  can  be  effectively  used 
and  how  individual  methods  relate  and/or  support  each  other.  For  data  collection  purposes, 
the  knowledge  of  several  methods  and  how  they  relate  to  each  other  will  allow  the  system 
designer  to  gather  data  with  multiple  applications  in  mind.  A  module  which  supports  the 
design  of  data  collection  instruments  should  clearly  outline  for  the  system  designer  how  to 
design  the  instrument  to  gather  data  for  multiple  modeling  activities.  The  rationale  behind 
this  project  is  that  the  technology  transfer  efforts  for  component  methods  should  be  centered 
around  the  development  of  a  structured  set  of  closely  interrelated  packages  that  build  upon 
each  other.  The  individuals  involved  in  technology  transfer  (training)  should  have  available 
to  them  a  tutorial  or  overview  that  allows  them  to  judge  the  areas  in  which  they  need  to  be 
trained  to  achieve  their  goals.  The  tutorial  should  provide  the  information  required  to  make 
informed  decisions  regarding  the  modules  that  should  be  studied  by  a  user. 

Approach:  The  approach  will  be  to  establish  a  structure  or  framework  that  will  allow  the 
development  of  an  easily  expanded  general  module  that  can  readily  accommodate  detailed 
packages  to  be  connected  to  it.  Once  the  framework  is  established,  a  prototype  general 
module  will  be  written  and  combined  with  at  least  three  detailed  modules  to  form  a  test 
package.  The  test  package  will  be  brought  to  the  user  community  and  trials  run  to  determine 
acceptability.  The  refinement  of  such  a  package  will  be  an  iterative  process  and  will  require  a 
great  deal  of  review  and  contact  with  the  user  community.  Each  module  will  be  documented 
in  a  workbook  format  and  a  roadmap  like  document  relating  the  overview'  module  with  the 
individual  modules  will  be  developed. 
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Resources:  This  project  will  require  at  least  one  author  for  the  overview  module  combined 
with  one  author  for  each  of  the  individual  modules.  Word  processing  software  and  some 
graphics  support  software  will  be  required. 

Timing:  A  minimum  of  six  months  will  be  required  to  complete  the  first  phase  of  this 
project.  Each  individual  module  can  be  prepared  in  parallel  with  the  overview  model  pro¬ 
viding  the  link  between  them.  Such  an  undertaking  will  require  four  months  of  concentrated 
writing  effort  with  two  months  of  review  and  coordination.  The  second  phase  will  require  six 
months  with  one  person  bringing  the  modules  to  industry  for  presentation  and  evaluation. 
Constraints:  This  project  can  be  started  immediately  and  scheduled  to  last  the  extent  of 
the  methods  development  process. 


Project  Title:  Component  Tool  Tutorials 

Project  Goals:  The  goal  of  this  project  is  to  develop  the  necessary  training  materials, 
exercises,  and  example  base  for  the  technology  transfer  of  the  component  automated  tool 
(both  traditional  and  knowledge  based)  transition  to  industrial  and  government  users. 
Project  Objectives:  The  objective  of  the  proposed  project  will  be  to  establish  a  foundation 
and  a  structure  for  a  tools  overview  module  and  for  the  modules  that  detail  each  individual 
tool.  The  initial  thrust  will  be  to  define  a  flexible  structure  that  can  be  added  to  as  tools 
evolve  and  as  new  interests  in  tools  evolve.  The  initial  deliverables  will  include  a  highly 
structured  overview  module  and  three  detailed  modules  illustrating  how  a  total  tools  package 
will  fit  together. 

Background:  The  purpose  of  this  project  will  be  to  develop  a  tutorial  type  of  educational 
package  which  will  provide  an  overview  of  the  component  tools  available  for  systems  mod¬ 
eling,  procedures  definition,  systems  design  logic,  system  architecture  definition,  and  other 
pertinent  design  areas.  As  a  secondary  goad  the  overview  will  be  supported  by  individual 
educational  modules  which  outline  in  detail  the  theory,  technical  qualities,  and  implementa¬ 
tion  strategies  for  each  of  the  individual  tools.  The  long  term  targets  will  be  to  build  a  large 
volume  of  educational  modules  for  technology  transfer  that  will  be  linked  together  through 
an  overview  or  tutorial  package  that  introduces  the  tools  to  the  student. 

Approach:  The  approach  to  this  project  is  similar  to  that  for  component  methods  tutorial 
development  with  the  addition  of  the  investigation  into  on-line  tutorial  structures  which  take 
advantage  of  the  functionality  of  the  tool  itself. 

Resources:  The  resources  required  for  this  project  are  estimated  at  one  man  year  per  tool. 
Timing:  The  time  period  planned  for  each  tool  tutorial  development  is  six  months. 
Constraints:  The  needs  and  design  approach  for  the  on-line  portion  of  the  tutorial  devel¬ 
opment  should  be  coordinated  with  the  component  tool  developers. 
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Project  Title:  System  Development  Environment  (SDE)  Tutorials 
Project  Goals:  The  goal  of  this  project  is  to  develop  the  necessary  training  materials,  ex¬ 
ercises,  said  example  base  for  the  technology  transfer  of  the  automated  System  Development 
Environment  (SDE)  transition  to  industry  and  government  users. 

Project  Objectives:  The  objective  of  the  proposed  project  will  be  to  establish  a  foundation 
and  structure  for  an  SDE  overview  module  and  for  the  modules  that  detail  each  individual 
common  utility  in  the  system  (i.e.  LCAM,  RCMU,  DCU). 

Background:  While  the  individual  component  methods  and  tools  will  have  limited  classes 
of  users,  the  SDE  (being  the  automated  integration  framework)  must  support  interaction  by 
many  different  classes  and  levels  of  users.  Therefore  specialized  tutorials  must  be  developed 
for  each  class  of  user. 

Approach:  The  approach  for  this  project  requires  the  initial  development  of  user  types  for 
SDE  use.  Once  these  user  classes  are  defined,  an  approach  identical  to  that  used  for  the 
component  tool  tutorials  can  be  applied. 

Resources:  The  resources  required  for  each  user  type  tutorial  is  one  man  year. 

Timing:  The  overall  development  time  required  for  this  project  is  estimated  at  16  months. 
Constraints:  This  project  should  be  initiated  during  the  detailed  design  phases  of  the  SDE 
development. 


Project  Title:  Integration  Framework  Tutorials 

Project  Goals:  The  USEE  “Frameworks”  provide  the  backbone  of  the  IISEE  application 
in  a  particular  environment.  The  goal  of  this  project  is  to  develop  the  training  materials  as¬ 
sociated  with  each  IISEE  framework  to  allow  correct  use  of  that  framework  by  management, 
project  administration,  and  technical  personel. 

Project  Objectives:  The  objective  of  this  project  is  to  develop  the  education  and  training 
modules  necessary  to  describe  the  philosophy,  implications,  and  applications  of  the  IISEE 
integration  frameworks  for  each  role  of  participant  in  an  IDS  application.  This  objective  also 
covers  the  education  modules  necessary  to  describe  the  IDS  standard  definition  and  how  to 
tailor  those  concepts  to  a  particular  implementation  site. 

Background:  The  integration  frameworks,  like  the  SDE,  must  be  understood  and  used  by 
a  large  class  and  variety  of  users.  Therefore,  specialized  tutorials  must  be  developed  for  each 
class  of  user.  The  guidebook  component  of  the  USEE  contains  a  description  of  the  general 
philosophy  of  IDS  implementaion  and  application  development  within  that  environment. 
However,  each  individual  participating  in  the  initial  IDS  implementation  or  maintenance 
must  specialize  those  concepts  and  relate  them  to  his  /  her  activities  in  the  associated 
framework  defined  procedure.  This  adds  a  level  of  complexity  to  the  development  of  training 
materials  for  transfer  of  framework  methods.  It  implies  that  the  training  approach  will  have 
to  be  heavily  oriented  towards  case  studies  and  group  practice  methods. 
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Approach:  The  approach  for  this  project  requires  the  initial  development  of  the  user  roles 
in  each  integration  framework  use.  Once  these  user  classes  are  defined,  an  approach  identical 
to  that  used  for  the  component  method  tutorials  can  be  applied. 

Resources:  The  resource  estimate  for  this  task  is  3  man  years  per  user  type.  The  additional 
effort  over  that  estimated  for  the  component  method  tutorials  is  due  to  the  case  study  nature 
of  the  framework  tutorials. 

Timing:  This  project  will  require  12  months  of  development  effort. 

Constraints:  This  project  should  run  in  parallel  with  the  framework  development  projects. 


Project  Title:  IISEE  Handbook  Series 

Project  Goals:  The  long  term  goal  of  this  project  will  be  to  establish  evolving  documen¬ 
tation  of  the  experience  base  of  industry  and  government  organizations  in  how  to  achieve 
information  integrated  systems. 

Project  Objectives:  The  objective  of  this  project  is  to  bring  together  experts  in  the  field 
of  integrated  systems  design  and  develop  a  series  of  textbooks.  Due  to  the  diversity  of  such 
a  set  of  authors,  the  books  would  have  to  be  written  as  a  handbook  under  the  guidance  of 
an  editor. 

Background:  Many  experts  in  the  field  of  integrated  systems  design  have  written  papers 
and  reports  of  significant  note.  These  papers  appear  in  a  far  reaching  va^ety  of  journals, 
conference  proceedings,  and  company  reports.  There  is  a  need  for  a  single  textbook  or 
handbook  in  this  field.  The  rationale  behind  the  project  is  that  the  technology  of  integrated 
design  systems  can  be  transmitted  to  a  very  far  reaching  audience  of  systems  people  through 
a  textbook. 

Approach:  The  editor  will  write  an  outline  for  the  handbook.  A  selected  advisory  board 
of  industry  and  university  experts  will  critique  and  shape  the  outline.  Once  the  outline  is 
stabilized  with  regard  to  content,  authors  will  be  selected.  The  advisory  board  will  suggest 
potential  authors.  Through  the  board’s  contribution,  the  editor’s  knowledge  of  the  field,  and 
a  literature  search,  authors  (contributors)  will  be  named.  According  to  the  topic  and  content 
of  the  sections  to  be  written  by  an  individual  author,  the  length  of  each  selection  should  be 
between  35-70  pages.  All  sections  of  manuscript  will  be  reviewed  by  industry  experts  and 
receive  approval  before  acceptance  for  publications. 

Resources:  This  project  will  require  an  editor  and  approximately  ten  authors  for  the  indi¬ 
vidual  sections  of  the  handbook.  The  time  to  write,  review,  and  edit  such  a  handbook  will 
be  two  years.  Of  most  importance  in  such  a  project  is  an  administrative  coordinator  to  track 
manuscripts  and  to  organize  the  manuscript  materials.  Assistants  (graduate  students)  will 
also  be  of  key  importance  to  this  type  of  project. 

Timing:  As  mentioned  above,  such  a  project  will  require  a  minimum  of  two  years  of  work 
for  the  editor  on  a  one-half  time  basis.  The  individual  authors  will  require  a  wide  range  of 
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times  depending  upon  their  experience  and  existing  manuscripts. 


Project  Title:  IISEE  Conferences 

Project  Goals:  The  goal  of  this  project  is  to  establish  a  forum  for  industry,  academic,  and 
government  exchange  of  ideas  and  experience  in  the  development  of  large  scale  integrated 
information  systems.  This  project  should  establish  the  basis  for  future  developments  and 
extensions  to  the  IISEE  to  be  supported  by  a  professional  network  of  practicing  system 
developers. 

Project  Objectives:  The  objective  of  this  project  is  to  organize  and  operate  a  yearly 
technical  conference  in  the  implementation  of  integrated  information  engineering. 
Background:  Open  technical  conferences  have  long  been  shown  to  be  one  of  the  most 
effective  mechanisms  for  technology  transfer.  This  is  particularly  true  of  technology  which  is 
largely  practice  and  experience  based.  One  of  the  shortfalls  of  the  previous  IDEF  and  1CAM 
SEM  method  development  initiatives  was  that  they  did  not  provide  this  forum  for  idea 
exchange.  Such  a  conference  would  not  only  provide  a  mechanism  for  the  exchange  of  ideas 
it  would  also  provide  a  forum  for  feedback  by  industry  to  the  IISEE  and  IDS  development 
programs. 

Approach:  The  organiztion,  promotion,  and  execution  of  a  successful  technical  conference 
is  a  major  undertaking.  The  recommended  approach  would  be  to  solicit  joint  sponsorship  of 
such  a  conference  by  existing  technical  societies  such  as  SME,  AIAA,  IEEE,  etc. 
Resources:  The  estimated  resources  for  this  project  is  one  man  year  per  year  for  the  life  of 
the  IISEE  program. 

Timing:  One  conference  per  year. 

Constraints:  Coordination  with  the  IDS  and  IISEE  program  offices  and  other  societies 
technical  conference  activities. 


Project  Title:  Managing  an  IDS  Implementation  Project 

P  set  Goals:  The  goals  of  this  research  and  development  effort  will  be  to  identify  and 
document  the  methods  and  tools  required  to  effectively  manage  an  IDS  type  of  project.  The 
long  term  targets  will  be  to  establish  a  comprehensive  educational  package  with  appropriate 
software  for  training  project  managers  in  the  practices  of  IDS  project  management. 
Project  Objectives:  The  main  objectives  of  this  work  will  be  to  expand  on  existing  project 
management  tools  and  software  to  satisfy  the  needs  of  IDS  projects.  Several  packages  such 
as  the  CPM  Based  Project  Managers  Workbench  and  the  Harvard  Project  Manager  software 
will  be  explored  for  possible  extensions  into  the  management  and  control  of  IDS  projects. 
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The  characteristics,  needs,  and  requirements  of  an  IDS  project  will  be  defined  and  used  as 
a  baseline  against  which  an  educational  package  will  be  structured.  Software  to  guide  and 
support  an  IDS  manager  will  be  written  to  automate  the  IDS  management  function. 
Background:  Project  management  provides  an  organization  with  the  tools  required  to 
improve  the  organization’s  ability  to  plan,  implement,  and  control  its  activities  and  the  way 
it  utilizes  scarce  resources.  When  a  project  must  be  completed  within  critical  time  constraints 
and  a  clearly  defined  set  of  outcomes  must  be  accomplished,  an  organized  set  of  procedures 
and  tools  must  be  utilized  to  plan  and  implement  such  a  program.  The  rationale  behind  the 
project  is  to  provide  the  current  project  managers  or  the  prospective  IDS  project  managers 
with  an  educational  package  that  will  allow  them  to  learn  the  basic  techniques  of  scheduling 
and  the  allocating  scarce  resources  to  accomplish  the  goals  of  the  IDS  program.  The  package 
will  be  structured  to  allow  the  manager  to  learn  through  independent  study  or  through  an 
instructor  lecture  format.  Case  studies  allowing  the  manager  to  gain  an  understanding  of 
the  problems  encountered  in  an  IDS  project  will  be  included  in  the  package. 

Approach:  The  approach  taken  will  be  to  establish  the  needs  of  the  IDS  program  manager 
within  the  context  of  the  systems  development  life  cycle.  Interviews  with  individual  respon¬ 
sible  for  the  development  of  integrated  information  systems  will  be  performed  to  determine 
through  their  experience  the  actual  program  management  needs.  Using  the  established  needs 
as  a  baseline,  existing  project  management  approaches,  software  said  concepts  will  be  modi¬ 
fied  or  developed  to  satisfy  the  program  needs.  After  testing  and  structuring  the  tools  into 
a  package,  a  technology  transfer  manual  for  use  by  program  managers  will  be  written.  The 
manual  will  contain  slides  for  use  in  an  instructor  lecture  format  and  narrative  for  use  with¬ 
out  an  instructor.  The  manual  and  the  narrative  will  be  tested  at  actual  facilities  and  case 
study  scenarios  will  be  developed  during  the  refinement  process.  The  educational  package 
will  consist  of  three  separate  volumes.  They  will  be  Volume  1  -  text  and  narrative,  Volume 
2  -  project  management  software,  Volume  3  -  case  studies  and  scenarios.  The  three  volumes 
will  be  coordinated  with  a  roadmap  type  of  structured  overview  document. 

Resources:  The  development  of  this  project  management  package  will  required  two  person- 
years  of  work.  The  individuals  involved  in  the  development  of  this  project  must  have  both 
project  management  and  software  development  skills.  Several  software  packages  will  have 
to  be  purchased  and  tested  to  determine  the  feasibility  of  their  application  in  the  context  of 
the  IDS  project  management  framework. 

Timing:  Although  the  project  will  require  two  man-years  of  effort,  the  calendar  time  for 
the  project  should  not  exceed  nine  months  to  one  year. 

Constraints:  The  major  constraints  for  this  project  will  be  locating  people  who  are  involved 
in  IDS  project  management  and  soliciting  their  ideas.  An  enabling  technology  will  be  the 
extensions  to  existing  software. 
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Chapter  4 


Method  Formalization 


This  chapter  consists  of  an  informal  account  of  a  formalization  of  the  information  modeling 
method  known  as  IDEFj  and  an  introduction  to  the  concept  of  a  neutral  representation 
scheme  as  a  basis  for  model  integration.  The  IDEFj  modeling  method  was  developed  around 
1980  for  the  US  Air  Force  to  support  aerospace  manufacturers  in  developing  an  understanding 
of  their  manufacturing  practices.  Although  widely  used,  it  has  never  been  subjected  to 
rigorous  formalization. 


4.1  Rationale 


Our  attempts  to  develop  rigorous  formalizations  of  existing  information  modeling  techniques 
have  been  motivated  by  the  following  observations  and  intuitions: 


•  Most  current  methods  for  information  modeling  have  evolved  as  a  distillation  of  “good 
practice”  experience  by  information  system  developers.  However  the  problems  facing 
developers  of  large-scale  integrated  information  systems  are  demanding  the  use  of  mul¬ 
tiple  techniques  and  the  extension  of  existing  techniques.  Our  intuition  tells  us  that  if 
we  had  a  better  understanding  of: 


—  what  the  current  techniques  can  and  can’t  do, 

—  why  the  current  techniques  do  or  don’t  work, 

—  how  one  technique  relates  to  another  technique, 


then  we  should  be  able  to  “design”  the  interfaces  between  existing  techniques,  predict 
the  extensions  that  are  needed,  and  to  design  any  needed  technique  extensions.  The 
reason  that  this  is  such  an  attractive  goal  is  that  we  would  like  to  avoid  the  cost  and 
pain  associated  with  discovering  voids  in  these  methods  through  a  series  of  failures  in 
the  systems  we  sire  currently  attempting  to  build. 
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•  The  process  of  building  integrated  information  systems  is  complex  enough  that  many 
different  models  using  different  methods  must  be  built.  Our  intuition  is  that  if  we  can 
define  the  formal  structures  of  these  modeling  methods,  then  we  will  be  able  to  develop 
a  more  general  representation  for  information  extracted  from  various  models  that  will 
ease  translation  and  evolution  from  one  modeling  method  to  another. 

•  The  systems  we  are  trying  to  build  (eg,  IDS  and  IISS)  require  the  direct  manipulation 
of  objects  defined  with  information  modeling  methods.  Without  an  unambiguous  way 
of  interpreting  what  those  models  mean  we  cannot  guarantee  that  the  systems  will 
work  the  way  we  intend.  We  also  find  that  an  inordinate  amount  of  guess  work  (gold 
dust  as  Bill  Putnam  calls  it)  is  required  on  the  part  of  design  and  implementation 
teams  in  attempting  to  interpret  the  models  that  are  being  produced. 

•  If  we  are  to  build  the  number  of  systems  required  of  the  complexities  currently  being 
contemplated  we  will  need  to  train  a  large  number  of  capable  practitioners  in  a  short 
period  of  time.  The  lack  of  rigorous  formalization  makes  it  difficult  to  train  new  people 
in  the  use  of  the  methods  and  also  makes  it  difficult  to  ascertain  the  competence  of 
those  who  have  been  trained. 

•  The  syntax  of  most  of  the  current  methods  were  designed  for  use  by  information  sytems 
personnel.  Experience  has  shown  that  the  information  needed  to  build  the  models 
must  be  acquired  from  domain  experts,  and  only  the  domain  experts  can  validate  the 
models.  If  through  the  formalization  process  we  can  separate  the  syntax  of  a  method 
from  the  information  that  syntax  is  meant  to  display,  then  we  can  design  alternative 
syntaxes  which  capture  and  display  the  same  information  in  a  form  more  palatable  to 
the  managers,  engineers,  and  manufacturing  domain  experts. 

•  One  of  the  stumbling  blocks  in  the  construction  of  automated  tools  for  support  of 
existing  methods  is  that  without  a  formal  definition  of  “what  the  symbols  mean”  it 
is  difficult  to  implement  anything  more  complex  than  drafting  and  dictionary  (text 
storage)  tools. 

•  In  order  to  be  able  to  construct  mechanisms  which  support  the  integration  of  methods, 
rad  to  provide  automated  support  for  the  transition  between  needs,  requirements  and 
designs,  there  is  a  need  for  a  deeper  understanding  and  representation  of  the  semantics 
of  the  models  constructed  using  existing  methods. 

•  Without  a  rigorous  definition  of  methods  there  is  no  way  clearly  to  compare  and  con¬ 
trast  various  techniques.  This  makes  it  very  difficult  for  companies  attempting  to 
perform  strategic  planning,  tactical  planning  and  design  to  choose  a  technique.  Minor 
syntactic  changes  can  be  used  to  hide  concept  identity,  and  major  conceptual  inconsis¬ 
tencies  can  be  introduced  with  informal  notions  that  “seem”  intuitively  correct.  The 
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demand  of  the  current  generation  of  potential  users  is:  No  representation  without  de¬ 
notation. 


4.2  Approach 

The  course  we  have  charted  involves  an  attempt  to  develop  a  formal  account  of  the  syntax 
and  semantics  of  four  information  modeling/database  design  methods  which  include:  IDEF}, 
IDEF1X,  ENALIivI,  and  ER.  Our  choice  to  begin  with  IDEFi  is  based  on  several  reasons. 
First,  it  is  a  well  conceived,  well  tested  modeling  technique  that  has  been  applied  effectively 
in  numerous  situations;  second,  the  authors  of  this  chapter  knew  they  would  in  the  course  of 
their  work  be  able  to  meet  several  times  at  length  with  Timothy  Ramey,  the  chief  architect 
of  IDEFj.  It  is  thus  to  IDEF1X  that  we  will  turn  our  attentions  after  the  completion  of  our 
formalization  of  IDEFi . 

The  process  for  formalizing  an  existing  methodology  turns  out  to  be  quite  arduous  and 
experimental  in  nature,  consisting  of  the  following  activities  (more  or  less  performed  in 
sequence  with  a  lot  of  looping  back): 

•  Examine  existing  documentation  for  the  technique  in  question  and  begin  extracting 
its  underlying  syntax  and  intended  semantics.  (If  possible,  this  first  stage  involves  the 
participation  of  the  original  developer(s)  of  the  technique.) 

•  Attempt  to  formalize  the  syntax  and  semantics.  This  involves  the  choice  of  a  lexicon 
and  the  development  of  formal  grammatical  rules,  and  the  design  of  an  appropriate 
mathematical  interpretation  of  the  syntax  in  terms  of  functions,  relations,  sets,  and 
other  mathematical  objects. 

•  Identify  problems  both  within  the  formalization  (e.g.,  possible  misinterpretations  of 
the  technique),  as  well  as  apparent  problems  uncovered  within  the  technique  being 
formalized  (e.g.,  identification  of  redundant  or  inconsistent  concepts  in  the  technique). 

•  Work  closely  with  the  original  developers  (t)  to  clear  up  misinterpretations,  (it)  to 
introduce  them  to  the  formalization  as  far  as  it  has  been  developed,  and  (tit)  to  gain 
their  assistance  and  guidance  in  continuing  the  formal  development. 

•  Show  that  each  well-formed  syntactical  “model”  generated  by  the  grammar  has  an 
interpretation,  i.e.,  a  set  theoretic  representation  of  a  possible  real-world  modeling 
situation.  This  ensures  that  the  grammatical  rules  axe  sound. 

•  Show  that  each  interpretation  can  be  represented  in  the  syntax.  This  ensures  that  the 
grammar  can  represent  any  possible  modeling  situation  which  it  is  designed  to  capture. 


•  Suggest  possible  extensions  to  the  modeling  technique  in  question. 


CHAPTER  4.  METHOD  FORMALIZATION 


147 


•  Begin  work  on  formal  comparisons  with  previously  formalized  modeling  techniques. 

•  Use  insights  gained  to  add  to  continuing  work  on  the  more  general  modeling  technique. 

•  Move  on  to  the  next  method. 

The  result  of  this  process  is  the  formalisms  themselves  and  a  documentation  of  the  prob¬ 
lems  uncovered  with  the  “perceived”  meanings  of  models  and  rules  for  constructing  those 
models,  and  the  actual  meanings  and  intended  rules. 


4.3  Informal  Presentation 

In  this  section,  we  will  talk  through  the  formal  syntax  of  IDEFx  along  with  the  intutive  and 
informal  semantics  that  informs  and  motivates  the  syntax. 

4.3.1  The  Syntax  and  Its  Informal  Semantics 

Formally,  IDEFi  is  treated  as  a  symbolic  system  with  two  components:  a  precisely  defined, 
but  wholly  uninterpreted  syntax,  and  a  set  theoretic  semantics.  In  this  respect,  our  approach 
resembles  exactly  the  standard  treatment  of  first-order  languages  and  their  semantics  in  the 
branch  of  mathematical  logic  known  as  model  theory.  (Though,  it  should  be  emphasized, 
it  would  be  inaccurate  to  think  of  IDEFi  as  a  first  order  language,  or  of  its  semantics  as  a 
first  order  semantics.)  The  syntactic  component  itself  consists  of  two  components:  a  lexicon 
and  a  grammar.  The  lexicon  for  the  IDEFj  formalism  consists  of  the  following  classes  of 
symbols:  upper  case  roman  A’s  with  numerical  subscripts,  which  we  call  entity  class  names; 
lower  case  roman  a’s  with  numerical  subscripts,  which  we  call  owned  attribute  names;  and 
upper  case  roman  L’s  with  numerical  subscripts  and  any  of  three  superscripts — an  arrow, 
a  bullet,  or  a  diamond — which  we  call  link  names.  In  practice,  of  course,  instead  of  single 
letters  one  would  use  words  intended  to  suggest  the  actual  semantics  of  the  names  in  the 
given  situation. 

Intuitively  (and  informally),  entity  class  names  denote  classes  of  what  we  might  call 
“the  information  image  of  objects,”  (or  conceptualized  objects)  rather  than  just  “objects”. 
(Note  carefully  that  we  are  talking  here  about  names  on  the  one  hand,  and  the  things  they 
denote  on  the  other.  Entity  class  names  denote  entity  classes,  but  entity  classes  themselves, 
being  nonlinguistic  sorts  of  things,  don’t  denote  anything.  This  crucial  distinction  was 
found  to  be  missing  or  confused  in  the  documentation  of  all  modeling  methods  reviewed 
to  date.)  The  reason  we  talk  about  conceptualized  objects  is  that  in  concept  modeling 
and  data  base  design  it  is  not  typically  real  world  objects  themselves  that  are  of  interest 
(we  can’t  write  an  employee  on  a  hard  disk),  but  rather  certain  clusters  of  information 
associated  with  real  world  objects  relative  to  their  (perhaps  manifold)  roles  within  a  given 
system.  The  different  roles  that  an  object  can  play  is  reflected  in  the  fact  that  the  pertinent 
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information  about  that  object  conceptualized  in  one  way  (e.g.,  as  a  mere  employee)  will  differ 
from  the  pertinent  information  about  the  object  conceptualized  in  another  way  (e.g.,  as  a 
corporate  executive).  The  object  thus  has  several  distinct  “projections”  or  “personae”  in  the 
informational  structure  of  the  system  corresponding  to  these  different  ways  of  conceptualizing 
it.  These  projections  are  the  conceptualized  objects,  hence  it  is  these  that  are  the  members 
of  entity  classes.1  Since  entity  classes  are  just  classes  of  similarly  conceptualized  objects,  and 
since  there  is  a  distinct  conceptualized  object  for  each  way  of  conceptualizing  a  given  real 
world  object  in  an  actual  system,  it  follows  that  we  cannot  have  the  same  conceptualized 
object  occurring  in  more  than  one  entity  class. 

The  differences  between  entity  classes  is  reflected  in  the  attribute  classes  associated  with 
the  entity  classes:  distinct  entity  classes  are  necessarily  associated  with  distinct  sets  of 
attribute  dassess;  indeed,  entity  classes  are  essentially  defined  by  their  associated  attribute 
dasses.  We  thus  need  to  take  a  doser  look  at  the  notion  of  an  attribute  dass.  Attribute 
dasses  come  in  two  varieties:  owned  and  inherited.  Intuitively,  owned  attribute  class  names, 
as  the  astute  reader  will  have  deduced,  denote  the  former.  Owned  attribute  dasses  are  simply 
those  attribute  dasses  that  are  uniquely  descriptive  of  the  members  of  a  given  entity  class, 
and  are  not  in  any  sense  “derived  from”  (about  which  more  shortly)  any  other  entity  class. 
Obvious  examples  here  are  attribute  dasses  like  emp#,  and  perhaps  also  typing  speed.  In 
the  formal  semantics  of  IDEFi,  attribute  dasses  are  functions  in  the  mathematical  sense.2 
That  is,  an  attribute  maps  each  member  of  a  given  entity  class  to  a  unique  value.  Thus, 
typing-speed  might  be  an  attribute  owned  by  the  entity  dass  SECRETARY,  which  would  map 
the  elements  of  that  dass  into  positive  integers  representing  the  number  of  words  per  minute 
each  secretary  can  type. 

Inherited  attributes  are  another  matter  entirely.  To  get  at  the  difference,  we  need  the 
notion  of  a  link.3  One  of  the  most  distinctive  features  of  an  information  system  is  that  the 
entities  in  the  system  are  all  interrelated;  none  of  the  conceptualized  objects  is  an  island. 
More  exactly,  it  is  entire  entity  dasses  that  are  interrelated.  We  can  parse  this  idea  in  terms 
of  links  between  entity  dasses.  Links  too  are  best  thought  of  as  functions,  though,  unlike 

1It  is  worth  mentioning  the  philosophical  connection  between  the  ideas  here  and  the  distinction  between 
sense  and  reference  introduced  by  Gottlob  Frege,  the  great  German  philosopher  and  inventor  of  modern  logic. 
Just  as  an  object  can  have  many  names  each  with  its  own  sense,  depending  on  how  the  name  was  introduced, 
so  an  object  can  have  many  distinct  personae  depending  on  the  roles  it  plays  in  the  system. 

*Given  this  view  it  is  confusing  to  use  the  term  “class”.  Therefore  in  the  remainder  of  this  chapter  we  will 
use  the  term  attribute  to  refer  to  what  Ramey  calls  attribute  classes.  It  should  be  noted  that  in  the  informal 
intuition  associated  with  the  IDEFt  the  distinction  is  very  important  since  one  of  the  points  that  Ramey 
was  attempting  to  clarify  is  the  need  to  build  “class  models”.  We  believe  that  is  a  unique  and  important 
contribution  which  has  unfortunately  been  overlooked  by  several  more  recent  developments. 

*What  we’re  calling  links  actually  correspond  more  or  less  to  what  Ramey  calls  link  classes.  Given  that 
link  names  correspond  semantically  to  functions,  Ramey’s  term  seemed  to  us  inappropriate.  What  Ramey 
calls  links,  i.e.,  particular  connections  between  two  elements  of  two  entity  classes,  we  can  call  something  else, 
e.g.,  connections,  or  perhaps  link  instances.  As  it  happens,  this  is  a  notion  that  is  unneeded  in  the  formal 
development  of  the  theory. 
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attributes,  ones  that  map  each  element  of  an  entity  class  to  a  single  element  of  another 
(possibly  the  same)  entity  class.  Thus,  the  link  works  .for  can  be  thought  to  map  each 
member  of  EMPLOYEE  to  a  unique  member  of  DEPARTMENT.  Note  that  link  functions  can  be 
composed  to  form  “longer”  links.  Thus,  is_part_of  might  be  a  link  that  maps  DEPARTMENT 
into  DIVISION,  and  hence  the  composition  (is  .part  .of  )•(  works  .for)  maps  EMPLOYEE  into 
DIVISION.  An  inherited  attribute  can  now  be  understood  straightforwardly  as  a  composition 
of  some  number  of  link  functions  and  an  owned  attribute.  Thus,  if  we  suppose  that  div# 
is  owned  by  DIVISION,  the  composition  of  div#  with  the  composite  link  above  yields  an 
inherited  attribute  of  the  members  of  EMPLOYEE  that  takes  each  member  to  his  or  her  division 
number. 

With  this  example  it  will  be  easy  to  show  how  inherited  attributes  are  represented  in  our 
grammar.  Let  ag  =  div#,  LJ  =  works -for,  and  LJ  =  is_part.of.  The  composite  link  from 
EMPLOYEE  to  DIVISION  is  thus  depicted  as  LJ-  LJ,  and  the  full-blown  inherited  attribute  as 
LJ-  L\-  ag.  Such  strings  of  link  names,  raised  dots,  and  an  owned  attribute  name  are  called 
inherited  attribute  names. 

Now,  as  noted  above,  each  role,  hence  each  entity  class,  is  determined  by  an  associated 
bunch  of  attributes.  Thus,  in  our  grammar,  we  will  group  together  entity  class  names 
with  attribute  names  (of  either  sort)  to  form  what  we  will  call  entity  class  schemes.  We 
need  to  fit  another  piece  into  the  puzzle  first,  however.  One  thing  that  is  required  in  any 
classification  of  entities  in  a  system  is  that  there  be  some  tangible  way  of  distinguishing 
any  particular  element  of  a  given  class  from  any  other.  More  specifically,  for  any  entity 
class,  there  must  be  some  nonredundant  (possibly  single-membered)  collection  of  attributes 
chosen  from  among  those  associated  with  the  entity  class  that  jointly  serve  to  identify  and 
distinguish  the  elements  of  the  class.4  Any  such  collection  will  be  called  a  key  class  for  that 
entity  class.  In  our  grammar,  key  classes  will  be  represented  by  strings  of  attribute  names 
enclosed  in  parentheses;  such  parenthetical  strings  will  be  called  (to  no  one’s  surprise)  key 
class  names.6 

We  now  have  four  different  syntactic  items  having  to  do  with  entity  classes:  entity  class 
names,  owned  attribute  names,  inherited  attribute  names,  and  key  class  names.  These  four 
we  combine  into  complex  expressions  that  we  call  entity  class  schemes.  Intuitively,  entity 
class  schemes  explicitly  display  the  full  logical  structure  of  an  entity  class.  We  construct 
them  in  the  following  way.  The  idea  here  is  to  squash  the  usual  IDEFi  boxes  with  their 
outgoing  arrows  flat  so  as  to  make  them  more  amenable  to  formal  treatment. 

First,  we  can  think  of  beginning  with  a  template  that  looks  like  this: 

4Such  a  collection  is  “nonredundant”  if  it  is  not  possible  to  remove  any  of  its  members  and  still  have  a 
collection  that  uniquely  distinguishes  the  elements  of  the  entity  class. 

‘Though  not  just  any  such  string  will  count  as  a  key  class  name.  For  various  reasons  we  will  not  go  into 
here,  for  example,  one  cannot  have  a  key  class  name  containing  two  inherited  attribute  names  such  that  the 
leftmost  link  name  in  one  is  many-one,  and  the  leftmost  link  name  in  the  other  is  one-one.  This  has  to  do  with 
important  facts  about  how  one-one  links  in  information  systems  function. 
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Then  we  stick  an  entity  class  name  out  front.  Next  we  fill  in  the  spaces  between  the 
angle  brackets  with  some  key  class  names  between  the  first  two,  some  inherited  attribute 
names  between  the  second  two,  and  some  owned  attribute  names  between  the  last  two  in  the 
following  way.  Let  e  stand  for  any  arbitrary  entity  class  name,  any  key  class  names, 

j  any  inherited  attribute  names,  and  any  owned  attribute  names  subject 

to  the  following  restrictions:  (*)  none  of  the  key  class  names  can  contain  all  the  attributes 
occurring  in  one  of  the  other  key  class  names;  (it)  every  one  of  the  inherited  attribute 
names  whose  leftmost  link  name  is  one-one  must  occur  in  one  of  the  key  class  names;  and 
(*i*)  every  owned  (inherited)  attribute  name  occurring  in  any  of  the  key  class  names  must 
appear  among  all  the  owned  (inherited)  attribute  names  between  the  angle  brackets.  (This 
latter  requirement  may  appear  redundant,  but  it  turns  out  to  be  very  convenient  for  formal 
purposes.)  Then  the  general  form  of  an  entity  class  scheme  is 

s[(/Ci,...,Kn){ti,...,ti)(w1,...,u;t)] 

6 

A  concrete  example  would  be  this.  Let  Ai  —  EMPLOYEE,  aj  =  amp#,  a2  =  dept#,  and  as 
above,  let  ag  =  div#,  LJ  =  works-for,  and  LJ  =  is_part_of.  Then,  supposing  first  that 
•mp#,  dept#,  and  div#  are  the  only  attributes  that  distinguish  the  entity  class  EMPLOYEE, 
and  that  each  element  of  the  class  is  identified  jointly  by  its  emp#  and  its  div#  our  entity 
class  scheme  would  look  like  this: 

Ai[((ai,  LJ-  LJ-  &3)){LJ-  LJ-  a3,  L*-  a2)(ai)]. 

If  we  let  A2  =  DEPARTMENT  and  A3  =  DIVISION,  the  entire  situation  between  these 
three  entity  classes  that  we’ve  envisioned  can  be  represented  as  in  the  more  familiar  looking 
graphical  IDEFi  diagram  seen  in  Figure  4.1. 7 

Once  we  have  our  legal  entity  class  schemes  in  hand,  the  grammar  tells  us  how  to  build 
proper  IDEFj  diagrams  out  of  them.  Specifically,  the  grammar  defines  one  entity  class 
scheme  E  to  be  linked  to  another  E'  via  some  link  name  A  just  in  case  A  is  the  leftmost 
constituent  of  some  inherited  attribute  name  i  occurring  in  E,  and  the  attribute  name  that 
results  from  deleting  A  from  t  occurs  in  E'.  In  Figure  4.1,  the  entity  class  scheme  A2  (more 
exactly,  the  entity  class  scheme  labeled  ‘A2’)  is  linked  to  A3  via  L2,  and  the  entity  class 
scheme  Al  is  linked  to  A2  via  Ll.  The  idea  of  one  entity  class  name  being  linked  to  another 

®In  constructing  a  formal  system  of  any  kind  one  must  use  a  metalanguage  to  talk  about  the  system  one  is 
constructing.  Often  in  such  a  process,  one  wishes  to  talk  about  the  members  of  an  entire  class  of  syntactic 
items  generally,  and  not  just  one  or  two  in  particular  from  a  given  class-  An  example  is  our  use  of  c  in  he 
general  form  of  an  entity  class  scheme  here  to  talk  about  all  entity  class  names,  and  not  just  about,  say,  A)  7. 
c  is  thus  an  example  of  a  metavariable.  It  is  important  to  realise  that  these  greek  letters  are  not  themselves 
part  of  the  language  but  axe  being  used  only  to  talk  in  general  terms  about  the  elements  of  the  language,  just 
as  one  might  (as  in  fact  we  have)  use  the  letters  i,j ,  and  k  to  talk  in  general  about  the  natural  numbers,  or 
A,B  and  C  to  talk  in  general  about  geometrical  lines. 

7The  diagram  in  Figure  4.1,  drawn  by  a  program  that  enables  one  to  create  IDEF,  diagrams  on  a  Symbolics 
Lisp  machine,  actually  uses  the  correct  notation  for  strong  many-one  link  names,  viz.,  a  solid  diamond.  It  was 
easiest  for  the  purpose  of  this  report  simply  to  use  bullets  in  the  text.  Note  also  that  in  actual  practice,  where 
there  is  no  danger  of  ambiguity,  the  link  names  in  an  inherited  attribute  name  can  be  suppressed. 
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reflects  syntactically  the  idea  of  one  entity  class  inheriting  an  attribute  from  another  via 
some  actual  link  between  them. 

Using  this  notion,  we  then  define  what  amounts  to  the  usual  graph  theoretic  notions  of 
a  path  and  a  walk  in  a  set  5  of  entity  class  schemes.  A  path  in  5  is  defined  to  be  increasing 
( decreasing )  if  each  entity  class  scheme  in  the  path — save  the  last — is  linked  to  its  successor 
via  a  one-one  (strong  many-one)  link  name,  and  cyclic  if  the  first  and  last  schemes  in  the 
path  are  identical.  A  walk  in  S  is  defined  to  be  increasing  just  in  case  the  result  of  changing 
all  the  strong  many-one  link  names  in  the  walk  to  one-one  link  names  is  an  increasing  path, 
and,  as  with  paths,  it  is  defined  to  be  cyclic  if  the  first  and  last  schemes  in  the  walk  are 
identical.  We  then  define  5  to  be  connected  just  in  case  there  is  a  walk  from  any  entity  class 
scheme  in  5  to  any  other.  Thinking  semantically,  the  idea  here  is  that  in  a  correct  account 
of  an  information  system,  one  should  be  able  to  find  a  route  from  any  given  entity  class  to 
any  other  by  traversing  either  forward  or  backward  along  the  links  between  entity  classes  in 
the  system.  The  natural  way  to  express  this  syntactically  (as  we  shall  do  below)  is  with  the 
requirement  that  the  set  of  entity  class  schemes  representing  the  system  be  connected. 

We  can  illustrate  these  concepts  pictorially  by  extending  Figure  4.1  to  Figure  4.2.  In 
Figure  4.2,  there  is,  among  others,  a  path  from  A4  to  A3  along  the  “links”  (more  correctly, 
link  names )  L3  and  L2,  and  one  from  A1  to  A4  along  the  links  Ll,  L2  and  L4.  While  there 
is  no  path  from  A4  to  Al,  there  is  a  walk,  in  fact  many  of  them.  One  can  traverse  forward 
on  the  link  L3  and  backward  on  the  link  Ll,  for  example,  or  backward  on  L4,  L2,  and  Ll. 
There  is  an  increasing  path  from  A3  to  A4  along  L4,  and  a  decreasing  one  from  Al  to  A3 
along  Ll  and  L2.  Finally,  there  are  several  cyclic  paths,  e.g.,  the  one  from  A2  to  A2  along 
L2,  L4,  and  L3.  The  diagram  is  obviously  connected,  as  there  is  a  walk  between  any  two 
entity  class  schemes.8 

Given  these  definitions,  we  define  a  set  5  of  entity  class  schemes  to  be  a  prediagram  if  it 
is  finite,  if  no  distinct  entity  class  schemes  share  the  same  entity  class  names  or  any  of  the 
same  attribute  names,  if  no  more  than  two  entity  classes  axe  linked  via  any  given  link  name, 
and  if  every  member  of  5  is  such  that  if  it  contains  an  inherited  attribute  name  i,  then  it 
has  to  be  linked  to  exactly  one  other  entity  class  scheme  in  5  via  the  leftmost  link  name 
in  t.  The  intuition  here  is  that  we  can’t  have  any  “dangling”  link  names  that  axe  attached 
to  an  entity  class  scheme  at  only  one  end;  semantically  put,  if  an  entity  class  includes  an 
inherited  attribute  among  its  distinguishing  attributes,  then  quite  obviously  there  has  to  be 
some  entity  clas«  from  which  it  is  inherited. 

In  order  for  a  prediagram  5  to  qualify  as  a  full-fledged  IDEFj  diagram,  we  require  (in 
addition  to  a  couple  of  restrictions  on  inheritance  we’ll  not  bother  with  here)  that  no  cyclic 
walk  be  increasing.  The  reason  for  this  is  that  the  only  way  that  such  a  walk  could  possibly 
represent  an  actual  information  system,  say,  would  be  if  all  the  links  in  the  walk  between 
entity  classes  were  always  one-one  and  onto.  But  by  the  nature  of  one-one  links,  entity 

’Figure  4.2,  however,  is  not  a  legal  diagram  as  it  stands,  since  no  key  class  name  is  inherited  by  A3  through 
L4. 
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classes  so  linked  would  have  to  be  ’’informationally  synonymous,”  and  hence  one  of  them 
would  be  superfluous.  As  a  rule,  the  identification  of  such  a  link  in  the  analysis  of  a  system 
indicates  the  presence  of  an  overlooked  attribute. 

4.3.2  Formal  Semantics 

The  discussion  above  indicates  pretty  clearly  how  the  formal,  set  theoretic  semantics  for 
the  formal  syntax  works.  The  basic  moves  go  like  this.  We  first  provide  interpretations 
for  the  elements  of  the  lexicon.  We  start  with  a  finite  set  of  mutually  disjoint  finite  sets. 
Intuitively,  these  represent  entity  classes,  and  are  the  semantic  values  of  entity  class  names. 
Link  names  are  assigned  functions  from  one  entity  class  to  another  (possibly  the  same)  entity 
class.  Next  we  have  another  set  of  sets,  intended  to  represent  owned  attribute  values.  Each 
owned  attribute  name  is  thus  assigned  a  function  from  an  entity  class  to  one  of  these  latter 
sets.  The  semantic  value  of  an  inherited  attribute  name  is  then  defined  recursively  as  the 
composition  of  the  semantic  values  of  the  attribute  names  (from  right  to  left)  that  make  it 
up. 

Next  we  say  what  it  is  for  such  an  interpretation  of  our  lexicon  to  satisfy  an  entity  class 
scheme.  This  will  be  the  case,  essentially,  if  the  functions  assigned  to  its  attribute  names 
take  the  class  C  assigned  to  its  entity  class  name  as  their  domain,  and  if  the  functions  in 
each  key  class  jointly  (and  nonredundantly)  identify  and  distinguish  the  members  of  C.  An 
interpretation  can  then  be  said  to  satisfy  a  set  of  entity  class  schemes,  and  in  particular,  an 
IDEFi  diagram,  just  in  case  it  satisfies  every  member  of  the  set. 

4.3.3  Metatheory:  Consistency  and  Completeness 

Once  we’ve  defined  the  formal  syntax  and  semantics  for  IDEF:  diagrams  there  are  a  few 
things  we’d  like  to  know  about  what  we’ve  defined.  Loosely  put,  we  want  to  know7  that  the 
syntax  and  the  semantics  “hook  up”  in  the  right  sort  of  way.  Somewhat  more  precisely, 
we  want  to  know,  first,  that  our  syntax  is  in  a  certain  sense  consistent.  That  is,  we  want 
to  know  that  the  rules  of  the  grammar  are  good  ones,  in  the  sense  that  they  only  allow  us 
to  construct  “coherent”  IDEFi  diagrams,  i.e.,  diagrams  that  could  be  used  to  characterize 
some  (perhaps  very  bizarre)  possible  information  system.  To  prove  this,  one  has  to  show  that 
every  IDEFi  diagram  that  the  grammar  generates  in  fact  has  an  interpretation,  in  the  formal 
semantical  sense.  At  present,  a  strong  partial  result  has  been  proved  for  all  noncyclic  IDEF) 
diagrams,  and  for  certain  cyclic  diagrams  that  are  not  in  a  certain  sense  too  “complex”. 
Early  indications  are  that  this  result  will  generalize  quite  straightforwardly  to  all  possible 
IDEFi  diagrams. 

The  second  thing  we  want  to  know  is  that  our  grammar  is  in  a  certain  sense  complete. 
That  is  to  say,  we  want  to  know  as  well  that  the  rules  of  the  grammar  axe  strong  enough 
to  be  able  to  capture  any  possible  information  system  that  we  can  construct  in  our  formal 
semantics.  This  is  quite  easy  to  prove,  given  the  rather  elaborate  and  specialized  nature  of 
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the  syntax;  for  given  some  formal  information  system  (as  defined  in  the  semantics)  one  is 
able  to  construct  an  IDEFi  diagram  straightaway  simply  by  reading  off  the  structure  of  such 
a  system  directly. 

It  is  important  to  realize  that,  with  these  proofs  in  hand,  one  is  guaranteed  that  the  IDEF] 
modeling  technique  is  sound — that  its  grammatical  rules  won’t  permit  senseless  diagrams, 
and  that,  relative  to  its  conception  of  the  structure  of  information,  there  is  no  possible 
situation  it  cannot  represent.  But  notice  that  these  results  are  possible  only  within  the 
context  of  a  rigorous,  mathematically  precise  formalization  of  the  technique’s  syntax  and 
semantics.  It  is  our  view  that  a  minimum  requirement  on  any  modeling  technique  should 
be  that  it  be  susceptible  to  similar  formalization,  and  that  it  be  provably  consistent  and 
complete  in  the  senses  developed  here. 

One  of  our  chief  goals  is  to  establish  that  this  requirement  can  be  met  by  all  the  modeling 
techniques  mentioned  at  the  beginning  of  this  chapter.  Once  established,  we  will  then  be 
in  a  position  to  compare  and  contrast  the  various  techniques  with  regard  to  their  views  of 
the  structure  of  information,  their  relative  expressive  power,  and  so  on.  And  perhaps  most 
important,  we  will  possess  the  necessary  theoretical  foundations  for  the  development  of  a 
neutral  information  representation  scheme  (NIRS). 


4.4  Neutral  Information  Representation  Language 

This  section  describes  the  concepts,  rationale,  and  preliminary  requirements  for  such  a  repre¬ 
sentation  scheme  referred  to  as  the  “Neutral  Information  Representation  Language”  (N1RL). 
In  concept  the  NIRL  is  intended  to  be  a  computer  processable  medium  for  representing  the 
results  of  application  of  the  component  methods  associated  with  an  TISEE  framework.  It 
might  better  be  thought  of  as  a  knowledge  representation  language  that  is  so  designed  as  to 
be  able  to  represent  the  knowledge  about  both  the  “AS  IS”  system  and  the  evolving  “TO 
BE”  system.  Its  primary  purpose  is  to  support  the  movement  of  information 

1.  Between  methods  in  a  particular  methodology  (e.g.  from  ENALIM  to  IDEF1-X). 

2.  Between  methods  in  different  methodologies  (e.g.  from  IDEFO  to  IDEF1-X). 

3.  Between  methods  used  in  different  phases  of  the  life  cycle  (e.g.  from  an  IDEF1-X  to  a 
Data  Structure  Diagram). 

The  endgame  envisioned  for  the  NIRL  is  illustrated  in  Figure  4.3.  Once  we  can  isolate  the 
information  gathered  and  the  information  displayed  by  a  method  then  we  want  to  be  able  to 
store  that  information  in  such  a  manner  that  it  can  be  used  in  other  stages  of  the  life  cycle, 
or  displayed  in  alternate  forms.  That  is,  it  was  the  experience  of  the  coalition  that  as  one 
moves  from  one  phase  of  the  development  process  to  the  next  much  of  the  information  which 
is  gathered  and  displayed  in  one  form  is  needed  in  the  next.  It  was  also  the  experience  of 
the  coalition  members  that  there  are  personal  and  organizational  preferences  for  particular 
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methods  within  a  methodology.  What  we  would  like  to  be  able  to  support  with  a  knowledge 
representation  system  designed  around  the  NIRL  is  the  ability  to  perform  deep  structure 
translations  between  the  methods. 

The  process  of  definition  of  the  NIRL  can  be  thought  of  as  a  collecting  together  of  the 
semantic  structures  uncovered  through  the  formalization  process  described  in  the  previous 
section.  These  concepts  then  must  be  analyzed  and  a  set  of  structures  defined  for  represen¬ 
tation  within  the  IISEE  environment. 
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Figure  4.3:  NIRL  Support  for  Methodology  Integration 


Chapter  5 


Natural  Language  Processing  of 
Manufacturing  Texts 


The  motivation  for  studying  the  application  of  natural  language  processing  (NLP)  on  infor¬ 
mation  models  such  as  IDEF  and  the  texts  and  glossaries  accompanying  them  lies  in  the 
practical  problems  with  building  models  (model  generation)  and  with  understanding  them 
(model  interpretation).  In  many  instances,  no  model  is  used  at  all  because  of  the  difficulties 
of  model  construction  and  the  time  required  by  that  activity.  In  other  cases,  models  that 
are  constructed  are  of  low  quality  or  are  not  uniform.  Moreover,  once  a  model  is  produced, 
users  often  have  trouble  understanding  it.  The  lack  of  compatability  between  different  types 
of  models  provides  a  further  hindrance  to  comprehension.  The  work  with  NLP  confronts 
these  problems  by  examining  the  feasibility  of  model  generation  from  English  sentences  (to 
assure  high  quality  and  uniformity),  the  feasibility  of  interpreting  the  information  content 
of  the  models  in  English  sentences,  and  the  feasibility  of  using  NLP  as  a  device  for  model 
translation  using  the  NIRL  developed  as  part  of  this  project. 

To  explore  the  feasibility  of  NLP,  we  have  undertaken  four  activities,  which  include: 


1.  Conducting  a  survey  of  NLP  approaches  to  determine  which  would  be  most  useful  for 
our  particular  application. 


Performing  a  linguistic  analysis  of  a  set  of  manufacturing  texts  to  determine  whether 
or  not  NLP  was  possible.  These  texts  included  IDEF  models,  glossaries,  and  texts 
from  the  System  Environment  Document,  Integrated  Sheet  Metal  Center,  Volume  II, 
15  April  1982,  Boeing  Military  Aircraft  Company  and  a  list  of  business  rules  from 
the  Integrated  Design  Support  System  (IDS)  Technology  Review  No.  3,  August  1986 
and  free-format  manufacturing  text  collected  from  various  manufacturing  companies. 
Sample  texts  are  included  as  Appendix  A. 


3.  Prototyping  a  system  that  would  process  the  model  statements  from  the  Boeing  In¬ 
tegrated  Sheet  Metal  Center  System  Document  and  the  business  rules  from  the  IDS 
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Technology  Review. 

4.  Determining  the  most  feasible  kinds  of  applications  for  NLP. 


5.1  Approaches  to  Natural  Language  Processing 

Developing  a  natural  language  processing  system  (NLPS)  is  an  extremely  difficult  task, 
although  it  might  at  first  glance  seem  deceptively  easy  because  of  the  ease  with  which 
humans,  including  small  children,  manipulate  and  understand  language.  Understanding 
natural  language  involves  not  only  understanding  the  meaning  of  individual  words  but  also 
understanding  the  meaning  and  function  of  those  words  within  a  sentence  or  even  a  body 
of  discourse.  However,  many  English  words  are  ambiguous;  that  is,  the  same  word  can  be 
used  either  as  different  parts  of  speech  or  with  different  meanings.  Further,  in  developing 
an  applications-oriented  NLPS,  we  have  the  classic  problems  of  linguistic  theory,  including 
anaphora,  elipsis,  and  coordinate  conjunctions,  that  remain  open  research  questions,  as 
well  as  the  inherent  ambiguity  of  English  syntax.  Humans  process  ambiguity  because  of 
a  background  or  world  knowledge  that  sets  the  context  of  the  discourse  and  builds  a  script 
of  what  is  expected.  It  is  the  difficulty  of  building  into  a  NLPS  this  background  knowledge 
component  and  a  method  for  recognizing  the  functions  of  words  in  blocks  of  discourse  that 
makes  the  task  of  designing  computer  NLPS  so  difficult.  Our  emphasis  within  this  work  has 
been  to  constrain  the  difficulty  in  developing  a  NLPS  in  order  to  make  a  practical  application. 

A  NLP  consists  of  a  parser  and  a  semantic  interpreter.  The  parser  determines  the  syn¬ 
tactic  structure  of  a  sentence  while  the  interpreter  assigns  meanings  to  these  structures.  To 
assign  words  to  syntactic  categories  or  parts  of  speech,  the  parser  makes  reference  to  a  lexi¬ 
con.  Once  assigned  a  part  of  speech,  these  lexical  items  are  then  assigned  to  larger  syntactic 
structures  such  as  noun,  verb,  or  prepositional  phrases  according  to  a  grammar  component. 

In  its  simpliest  form,  the  lexicon  is  a  dictionary  of  possible  lexical  items  and  their  asso¬ 
ciated  syntactic  categories.  However,  such  a  simple  lexicon  has  a  serious  drawback:  many 
English  words  are  inherently  ambiguous  on  several  different  levels.  First,  a  word  may  be 
syntactically  ambiguous,  with  several  possible  category  assignments.  Thus  the  word  run 
may  be  either  a  noun  or  verb;  the  word  that  may  be  a  pronoun,  determiner,  or  subordinator. 
Second,  a  word  may  be  lexically  ambiguous,  with  several  different  meanings  associated  with 
the  same  syntactic  category,  as  in  the  word  run  which  can  be  used  as  either  a  verb  or  a 
noun.  As  a  verb,  it  has  a  range  of  meanings  from  “run  a  race”  to  “run  away”  to  “run  a  risk” 
to  “run  a  fever”,  while  as  a  noun  it  can  have  such  various  meanings  as  in  “a  10K  run”  “a 
long  run”  “the  usual  run  of  men”,  or  “a  run  in  my  stockings”.  Humans  easily  process  and 
understand  these  various  senses  because  of  the  semantic  cues  provided  by  the  larger  body 
of  discourse.  Unfortunately,  a  large  number  of  English  words  are  ambiguous  in  one  or  both 
ways.  However,  because  the  language  of  the  models  is  so  restrictive,  much  of  the  lexical 
amibiguity  is  eliminated  in  our  task,  but  the  problem  of  syntactic  ambiguity,  as  discussed 
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below,  still  remains. 

The  best  strategy  for  actually  parsing  and  understanding  sentence  components  of  text  is 
an  open  research  question.  Of  the  many  prevailing  approaches  to  NLPS,  most  fall  into  two 
broad  categories  —  linguistic  (syntax  driven)  or  conceptual  (semantics  driven).  Linguistic 
systems  maintain  the  parser  and  interpreter  as  separate  components,  but  conceptual  systems 
use  some  elements  of  the  interpreter  to  constrain  the  parser.  One  such  constraint  mechanism 
is  the  use  of  case  frames,  that  is  the  assignment  of  syntactic  categories  based  on  the  semantic 
/  syntactic  relationship  of  constituents  to  the  predicate  of  the  sentence.  Another  is  the  use 
of  a  sublanguage  system,  or  a  lexicon  constrained  by  a  particular  domain. 

Linguistically  based  systems  rely  primarily  on  knowledge  of  grammar  (the  syntax  and 
morphology  of  a  particular  language)  rather  than  on  knowledge  of  a  particular  domain. 
Because  these  systems  are  syntax-driven,  they  may  actually  generate  several  meanings  for  the 
same  sentence  and  may  in  fact  generate  interpretations  that  make  no  sense  in  the  real  world. 
Conceptual  parsers,  on  the  other  hand,  are  guided  in  their  parsing  by  their  knowledge  of  some 
domain  and  thus  eliminate  interpretations  which  have  no  meaning  for  a  particular  domain. 
However,  since  conceptual  systems  are  domain-specific,  they  cannot  easily  be  generalized 
without  the  regeneration  of  the  knowledge  component.  The  grammar  in  a  linguistic  parser 
usually  consists  of  a  set  of  phrase  structure  rules  used  to  bundle  syntactic  categories  into 
syntactic  constituents,  but  in  a  conceptual  parser  the  grammar  forms  a  set  of  sentence 
patterns  anticipated  by  the  system.  Conceptual  parsers  attempt  to  incorporate  some  of  the 
human’s  ability  to  disambiguate  by  providing  extensive  knowledge  about  a  limited  domain, 
thus  imposing  severe  constraints  on  the  use  and  co-occurrence  of  certain  lexical  items.  For 
instance,  in  a  conceptual  parser,  the  verb  snore  would  require  a  human  agent  and  an  optional 
indicator  of  manner.  These  constraints  are  imposed  by  syntactic  category  restrictions  on 
words  in  the  lexicon  and  by  case  frames  associated  with  verbs. 

Regardless  of  the  approach,  parsers  accept  as  input  a  subset  of  the  text  (we  will  assume 
a  sentence  by  sentence  parse)  and  match  each  lexical  item  (or  word)  with  possible  syntactic 
categories  (or  parts  of  speech).  The  string  of  syntactic  categories  are  bundled  into  larger 
and  larger  syntactic  constituents  by  the  parser  until  the  sentence  can  be  processed,  and  the 
information  content  of  the  sentence  incorporated  into  some  representation  strategy. 


5.2  Conceptual  Parsing  Approach 

In  our  work  we  have  adopted  the  conceptual  approach  because  we  believe  that  successful, 
efficient  text  processing  and  understanding  depends  upon  building  a  computer  system  that 
combines  grammatical  knowledge  with  the  expectations  and  constraints  that  an  analyst 
brings  to  understanding  a  model  and  its  associated  text  and  glossaries.  Thus  we  reject 
the  notion  for  this  application  that  a  parser  can  operate  autonomously  on  syntax  without 
regard  to  the  domain  of  discourse.  Our  parser  uses  expectations  of  textual  organization  built 
into  patterns  based  on  the  structure  of  the  material  as  well  as  grammatical  expectations  or 
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case  frames.  For  this  reason,  our  system  would  not  understand  texts  which  lie  outside 
that  domain.  The  patterns  for  manufacturing  texts  would  expect  only  data  relating  to  a 
manufacturing  process,  and  further,  only  the  kinds  of  data  required  by  an  IDEF  model  (that 
is,  information  descriptions)  in  one  case  and  business  rules  from  the  IDS  Technology  Review- 
in  the  other.  The  patterns  also  anticipate  either  the  verb  and  preposition  or  the  verb  and 
case  frame  co-occurence  structures  that  help  establish  case  frames  .  Since  these  structures 
are  complex,  the  parser  must  sometimes  rely  on  a  scale  of  probability  for  understanding  the 
meanings  of  lexical  items  which  have  a  wide  range  of  meanings.  Our  parser,  for  instance, 
would  attempt  to  understand  run  as  referring  to  a  job  (as  a  verb)  or  perhaps  to  a  completed 
job  (as  a  noun);  it  would  not,  however,  understand  “run  in  a  stocking”  or  other  meanings  of 
run  outside  of  the  manufacturing  domain. 

Our  parser  makes  use  of  two  other  devices.  First,  we  have  tried  to  establish  a  grammar 
of  the  sublanguage  associated  with  manufacturing.  Thus,  in  the  case  of  model  descriptions, 
we  have  tried  to  determine  through  a  manual  analysis  of  relevant  texts,  the  set  of  verbs 
commonly  used  to  establish  entity  and  attribute  relationships,  the  constraints  on  the  possible 
meanings  of  those  verbs,  the  caseframes  normally  associated  with  those  verbs,  and  the  range 
of  syntactic  patterns  which  occur.  We  have  completed  a  similar  analysis  for  the  business 
rules  from  the  IDS  Technology  Review.  Second,  we  have  utilized  a  “minimal  lexicon”  or  a 
pattern-based  approach  that  does  not  require  that  all  nouns  and  adjectives  be  in  the  lexicon 
for  correct  parsing.  Parsing  is  accomplished  on  the  basis  of  the  grammatical  and  conceptual 
constraints,  as  coded  into  a  case  grammar,  developed  in  the  manual  analysis. 

In  the  restricted  domain  established  by  the  IDEF  model  texts,  for  example,  we  have 
structured  our  set  of  patterns  to  expect  text  in  the  third  person.  For  instance,  we  certainly 
do  not  expect  imperative  sentences.  In  fact,  in  the  glossary  definition,  many  sentences  which 
“appear”  to  be  imperative  (lacking  a  subject  and  beginning  with  a  verb)  are  simply  definitions 
where  the  missing  subject  is  assumed  to  be  the  entity  class  label  as  shown  in  Figure  5.2. 
In  other  cases  (especially  in  the  definitions  of  entities  and  attributes)  both  a  subject  and 
verb  are  missing:  that  is,  a  sentence  fragment  is  used  in  the  definition.  The  subject  again 
is  the  entity  class  label,  but  in  this  instance  the  verb  must  be  inferred  by  the  reader.  (Note 
that  this  is  the  typical  practice  in  both  commercial  and  scholarly  lexicography.  Definitions 
are  given  as  sentence  fragments  and  especially  as  complements  of  verbs.  The  head  word 
supplies  the  missing  subject,  while  the  reader  infers  the  verb.)  Supplying  missing  subjects 
in  the  glossaries  is  a  trivial  parsing  problem;  the  correct  verb  is  usually  a  form  of  be  (an  is  a 
relationship,  for  example)  with  entity  classes  as  shown  in  Figure  5.2.  With  attribute  classes, 
the  problem  is  somewhat  more  complex  requiring  more  study. 

Further,  these  patterns  are  associated  with  processing  case  frames  which  anticipate  cer¬ 
tain  types  of  information  once  the  verb  phrase  is  isolated.  Since  this  information  is  often 
denoted  by  the  co-occurrence  of  verbs  and  prepositions  or  verbs  and  syntactic  functions  (such 
as  subject  or  direct  object),  our  processor  is  tuned  to  search  for  the  anticipated  semantic 
casemarkers. 
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5.3  Text  Analysis 

As  a  first  attempt  at  establishing  the  IDEF  sublanguage,  we  did  a  manual  analysis  of  the 
approximately  2400  model  statements  in  the  Boeing  Integrated  Sheet  Metal  Center  System 
Document,  one  of  the  most  complete  IDEF  models  available.  The  IDEF  statements  set  up 
relationships  between  entity  classes  which  correspond  to  the  relationships  depicted  graph¬ 
ically  on  the  models,  and  thus,  provide  an  ideal  test  case  for  NLP  on  the  IDEF  models. 
These  model  statements  also  demonstrate  the  importance  of  the  verb,  which  sets  up  en¬ 
tity  relationships  in  the  manufacturing  sublanguage.  Figure  5.3  provides  a  representative 
sample  of  the  model  statements  which  we  analyzed  manually.  In  these  2400  statements,  we 
found  that  only  53  verbs  occurred,  and  with  these  53,  a  limited  set  of  caseframes  occurred. 
Among  the  common  caseframes  axe  agent  (performer  of  actions),  object  (thing  acted  upon 
or  defined),  locative  (the  place  where  things  occurred),  equaiive  (which  equates  two  things), 
temporal  (time  when  something  occurs),  dative  (the  thing  or  person  to  whom  or  for  whom 
the  action  takes  place),  manner  (how  something  is  accomplished),  and  source  (the  basis  of 
an  action).  FVirther,  not  all  cases  occur  with  all  verbs.  In  fact,  there  axe  severe  constraints  on 
the  distribution  of  cases  and  our  parser  relies  heavily  on  these  constraints.  Caseframes  can 
be  identified  by  one  of  two  means  —  the  occurrence  of  certain  prepositions  or  word  order. 
The  meaning  associated  with  prepositions  is  totally  dependent  upon  the  verb  with  which 
they  co-occur.  The  same  preposition  may  signal  different  cases  with  different  verbs.  For 
example,  with  some  verbs  in  signals  a  locative  case,  while  with  others  it  signals  a  temporal 
case.  Further,  in  functions  as  a  verb  particle  with  the  verb  result.  What  disambiguates  the 
uses  of  in  is  the  co-occurrence  with  a  particular  verb.  These  findings  confirm  our  hypothesis 
that  information  models  make  use  of  a  highly  restricted  sublanguage  and  leads  us  to  believe 
that  at  least  some  NLP  is  possible  in  model  generation  and  interpretation.  (The  business 
rules  from  the  IDS  Technology  Review’  provided  a  different  kind  of  problem,  but  after  a 
similar  kind  of  manual  analysis,  we  believe  that  NLP  is  also  possible  with  these  texts.  While 
a  wider  range  of  syntactic  structures  occurs  in  the  texts,  they  can  be  parsed  through  the 
mechanism  of  successive  parsing.  For  example,  discontinuities  in  the  verb  phrase  can  be 
resolved  in  a  preprocessing  stage,  thus  enabling  an  accurate  parse  of  the  sentence. 

The  linguistic  analysis  of  these  two  kinds  of  texts  also  reveals  several  interesting  parsing 
problems.  First,  there  is  the  syntactic  ambiguity  of  words  such  as  manufacturing ,  request , 
charge,  drawing,  support,  and  issue.  Each  of  these  words  can  be  used  as  both  nouns  and 
verbs  or  adjectives  and  verbs.  This  ambiguity  creates  insurmountable  problems  for  purely 
syntactic  parsing.  In  such  instances,  heuristic  devices  have  to  be  used  to  disambiguate  the 
sentences.  Second,  the  analysis  reveals  that  the  key  to  parsing  the  text  lies  in  locating  the 
verb.  In  the  IDEF  models,  the  case  frame  structure  associated  with  the  verb  is  closely 
associated  to  the  relationship  between  entities.  These  entities  are  in  fact  components  of  the 
case  frames.  This  last  finding  is  particularly  useful  in  light  of  the  structure  of  IDEF  models, 
which  capture  the  entity  /  relationships.  In  the  business  rules  from  the  IDS  Technology 
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1.  Rework  orders  are  reworked  according  to  withhold  tag  item. 

2.  Tool  type  conforms  to  tool  specification. 

3.  Resource  need  identifies  requirement  for  resource  plan. 

4.  With  hold  tag  item  becomes  certified  part  after  rework. 

5.  WOP  validation  verifies  the  contents  of  work  order  packages. 
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Figure  5.3:  Representative  Sentences  Which  the  Prototype  Can  Understand 
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Review,  however,  the  interaction  of  verbs  and  cardinality  relationship  (for  example,  one  and 
only  one;  or  zero,  one,  or  many)  provides  the  semantic  core  of  the  sentences. 

5.4  Prototype  System  for  EDEF  Statements 

Using  the  information  from  the  text  analysis,  we  developed  a  prototype  parser  which  parses 
almost  all  of  the  2400  model  statements  in  the  Boeing  Integrated  Sheet  Metal  Center  System 
Document.  Fbr  our  prototype,  we  are  utilizing  the  Language  Craft™,  a  product  of  Carnegie 
Group  Inc.  because  it  utilizes  the  caseframe  grammar  which  forms  the  basis  of  our  linguistic 
analysis. 

5.5  Prototype  System  for  Business  Rules 

A  second  prototype  system  was  developed  for  the  business  rules  from  the  IDS  Technology 
Review.  Again,  Language  Craft™  was  utilized  for  the  prototyping.  These  business  rules 
establish  cardinality  or  hierarchical  constraints  using  grammatical  constructs  such  as  is  a 
type  of,  is  for  exactly  one,  has  zero,  one,  or  many,  has  exactly  one. 

5.6  Future  Work 

Using  these  prototypes  as  a  basis,  we  are  pursuing  four  other  activities.  First,  it  would  be 
beneficial  to  implement  an  “Automated  Model  Generator”  (AMG)  which  would  provide  a 
“workbench”  capability  for  building  IDEF  models.  Such  a  tool  would  have  the  advantage  of 
making  models  easy  to  draw  and  of  providing  uniformity  and  consistency  checking.  Starting 
with  statements  similar  to  the  statements  in  the  Boeing  Integrated  Sheet  Metal  Center 
System  Document,  the  AMG  would  produce  graphic  representations  of  entity  relationships 
automatically. 

A  second  activity  would  develop  an  “Automated  Model  Interpreter”  (AMI)  which  would 
generate  all  English  sentences  which  explain  the  implications  of  the  IDEF  models.  This 
tool  would  have  the  advantage  of  making  explicit  the  consequences  of  a  model  and  would 
be  significant  step  forward  in  providing  the  user  an  understanding  of  the  models.  The  AMI 
would  begin  with  graphic  representations  and  have  as  its  output  English  sentences. 

A  third  activity,  much  further  in  the  future,  would  interpret  the  glossary  and  texts  asso¬ 
ciated  with  IDEF1  models.  This  is  a  far  more  complex  application  unless  some  restrictions 
are  placed  on  the  syntax  used  in  text  and  glossaries.  Essentially,  four  problems  present 
themselves.  The  first  problem  is  a  “pseudo”  problem  of  processing  the  sentence  fragment 
structure.  In  fact,  the  subject  of  these  sentences  can  be  inferred  from  entity  labels  and  the 
verb  is  generally  a  form  of  he.  The  other  problems  are  more  complex.  For  one  thing,  the  glos¬ 
saries  contain  a  very  broad  range  of  syntactic  structures  including  embedded  sentences.  The 
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texts  themselves  contain  a  much  larger,  unconstrained  set  of  verbs  and  relationships  as  well 
as  a  broad  range  of  syntactic  structures.  Both  of  these  problems  require  an  extremely  robust 
grammar,  a  significant  lexicon,  and  an  extensive  set  of  heuristics  to  account  for  potential 
ambiguities.  Finally,  the  last  problem  deals  with  the  complex  set  of  relationships  between 
attribute  types  and  entities.  Here  parsing  will  require  extensive  background  knowledge  of  a 
particular  manufacturing  domain. 

The  fourth  activity  involves  providing  information  for  the  development  of  the  NIRS  (Neu¬ 
tral  Information  Representation  System).  This  activity  requires  the  establishment  of  canon¬ 
ical  sets  of  verbs,  entities,  and  relationships.  It  is  the  most  far-reaching  of  the  four  activities 
and  the  one  with  the  most  general  set  of  applications.  We  have  already  begun  work  on  es¬ 
tablishing  canonical  sets  of  verbs.  For  example,  in  the  Boeing  Integrated  Sheet  Metal  Center 
System  Document,  we  have  been  able  to  classify  the  53  verbs  into  12  categories  based  on 
the  relationships  they  depict.  Further  work  may  enable  us  to  classify  these  into  even  fewrer 
categories. 
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T6  3 , Tl 2  0 

~  1  '  ~ 

173 

An  instance  of  COORDINATE  SYSTEM 

globally  defines  zero,  one  or  many  ITEM  VERSION  LOCATION 

279 

T63 , T114 

An  instance  of  COORDINATE  SYSTEM 

locally  defines  direction  of  zero,  one  or  many 

ENVIRONMENT 

277 

T6  3 , Tl 0  3 

An  instance  Of  COORDINATE  SYSTEM 

locally  defines  zero,  one  or  many  MODEL  NODE  LOCATION 

281 

T6  3 , T7  2 

An  instance  of  COORDINATE  SYSTEM 

locally  defines  zero,  one  or  many  GEOMETRY  ELEMENT 

118 

T64  ,  T4  4 

An  OPERATIONAL  ITEM  VERSION 

is  a  function  type  of  ITEM  VERSION  FUNCTION 

421 

T64 , T224 

An  instance  of  OPERATIONAL  ITEM  VERSION 
has  zerc,  one  cr  many  STORAGE  LOCATION 

424 

T64 , Tl 92 

An  instance  of  OPERATIONAL  ITEM  VERSION 

has  zero,  or.e  or  many  PACKAGE  OPERATIONAL  ITEM 

423 

T64 , T172 

An  instance  of  OPERATIONAL  ITEM  VERSION 

has  zero,  one  or  many  OPERATIONAL  ITEM  VERSION  LSA  TASK 

422 

T64 , Tl 7  8 

An  instance  of  OPERATIONAL  ITEM  VERSION 
has  zero,  one  or  many  MAINTENANCE  HISTORY 

425 

T64  ,  Tl 6 9 

An  instance  of  OPERATIONAL  ITEM  VERSION 

is  used  as  equipment  for  zero,  one  or  many  LSA  TASK  OSE 

130 

T64  ,  T3 8 

An  instance  cf  OPERATIONAL  ITEM  VERSION 

relates  to  zero,  one  or  many  MANUFACTURING  OPERATIONAL 
ITEM  VERSION 

132 

T64 ,T36 

An  instance  of  OPERATIONAL  ITEM  VERSION 

relates  to  zerc,  one  u  many  ENGINEERING  OPERATIONAL  ITEM 

VERSION 

164 

T6  5 , Ti 1 

An  instance  cf  SIMULATED  ITEM  VERSION 
is  modeled  by  exactly  or.e  ITEM  VERSION 

169 

T6  5 , Tl 1 

An  instance  of  SIMULATED  ITEM  VERSION 
models  exactly  one  ITEM  VERSION 

78 

T66 , Til 

An  instance  of  PACKAGE  ITEM 
contains  exactly  one  ITEM  VERSION 

76 

T66 , T29 

An  instance  of  PACKAGE  ITEM 
is  included  in  exactly  one  PACKAGE 

24  8 

T67 ,T63 

An  instance  cf  ITEM  VERSION  ENVIRONMENT  LOCATION 
has  location  defined  by  exactly  one  COORDINATE  SYSTEM 

250 

T67 , Til 

An  instance  cf  ITEM  VERSION  ENVIR  NMENT  LOCATION 
is  for  exactly  cr. e  ITEM  VERSION 

290 

T6  7 , Tl I 4 

An  instance  cf  ITEM  VERSION  ENVIRONMENT  LOCATION 
is  for  exactly  one  ENVIRONMENT 

p 
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419 

T29 , T168 

-  S- 

A  PACKAGE  v. 

may  be  a  REPROCUREMENT  PACKAGE  '  * 

67 

T29 , T4  3 

An  instance  of  PACKAGE 

includes  zero,  one  or  many  PACKAGE  DOCUMENTED  DATA 

75 

T29 , T66 

An  -instance  of  PACKAGE 

includes  zero,  one  or  many  PACKAGE  ITEM 

580 

T29 , T192 

An  instance  of  PACKAGE 

is  applicable  to  zero,  one  or  many  PACKAGE  OPERATIi 
ITEM 

135 

T30 , T1 1 

An  instance  of  SERIALIZED  ITEM  VERSION 
is  for  exactly  one  ITEM  VERSION 

111 

T31 , T3  9 

An  OPERATIONAL  ITEM  USAGE 

is  a  function  type  of  ITEM  USAGE  FUNCTION 

61 

T32 , T51 

An  instance  of  INVOKED  DOCUMENTED  DATA  REVISION 
is  for  exactly  one  DOCUMENTED  DATA  ( DD )  REVISION 

62 

T32  , T54 

An  instance  of  INVOKED  DOCUMENTED  DATA  REVISION 
limits  exactly  one  INVOKED  DOCUMENTED  DATA 

45 

T33 , T51 

A  MANUFACTURING  AND  OPERATIONAL  ANALYSIS  DOCUMENT 
is  a  type  of  DOCUMENTED  DATA  ( DD )  REVISION 

102 

T34 , Til 

An  instance  of  ITEM  VERSION  DOCUMENTED  DATA  REVISION 
defines,  evaluates,  and/cr  acts  upon  exactly  one 
VERSION 

64 

T3  4 , T51 

An  instance  of  ITEM  VERSION  DOCUMENTED  DATA  REVISION 
is  for  exactly  one  DOCUMENTED  DATA  (DD)  REVISION 

3 

T3  5 , T51 

An  ENGINEERING  ORDER 

is  a  type  Of  DOCUMENTED  DATA  (DD)  REVISION 

127 

T36 , Tl 6 

An  instance  of  ENGINEERING  OPERATIONAL  ITEM  VERSION 
is  related  to  exactly  one  ENGINEERING  ITEM  VERSION 

133 

T36  ,  T64 

An  instance  of  ENGINEERING  OPERATIONAL  ITEM  VERSION 
is  related  to  exactly  one  OPERATIONAL  ITEM  VERSION 

5 

T37  ,  T51 

A  PRODUCTION  PLAN 

is  a  type  cf  DOCUMENTED  DATA  ( DD )  REVISION 

129 

T38  ,  T24 

An  instance  of  MANUFACTURING  OPERATIONAL  ITEM  VERSION 
is  related  to  exactly  one  MANUFACTURING  ITEM  VERSION 

131 

T38 , T6  4 

An  instance  of  MANUFACTURING  OPERATIONAL  ITEM  VERSION 
is  related  to  exactly  one  OPERATIONAL  ITEM  VERSION 

113 

T39 , T2  5 

Ar.  ITEM  USAGE  FUNCTION 

may  be  a  MANUFACTURING  ITEM  USAGE 

112 

T39 ,T3 

An  ITEM  USAGE  FUNCTION 

m. 


may  be  an  ENGINEERING  ITEM  USAGE 
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AI33  EXAMINE  STAFF  SL  ILLS  STILLS  ANALYSIS  TOOL 

A 1 34  EXAMINE  SYSTEM  ARCHITECTURE  HARDWARE /St JFT WARE  ANALYSIS  TOOL 

A 1 35  EXAMINE  INFORMATION  FLOW  DATA  FLOW  ANALYSIS  TOOL 
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(DRAFT) 


A-l  OPERATE  BUSINESS 

This  activity  covers  the  development,  administration  and  monitoring  of 
the  business  strategy.  The  business  strategy  includes  the  goals  that 
the  enterprise  intends  to  attain  and  the  direction  that  the  enterprise 
must  take  in  order  to  acheive  these  goals. 


A-l 1  DEVELOP  BUSINESS  STRATEGY 

This  activity  focuses  on  the  development  of  a  workable  business 
strategy.  The  first  step  is  to  evaluate  strategic  concepts.  The 
concept  evaluation  process  lays  the  groundwork  for  a  more  comprehensive 
definition  of  strategic  goals  of  the  enterprise.  Strategic  concepts 
are  evaluated  and  chosen  to  be  incorporated  into  the  business  strategy 
as  strategic  goals.  Once  the  strategic  goals  have  been  thoroughly 
defined  and  final  approval  has  been  given  as  to  their  validity,  they 
are  prioritised  for  initiation. 

A-l 2  ADMINISTER  BUSINESS  STRATEGY 

Prioritised  stategic  goals  of  the  enterprise  are  utilised  dut  mg  this 
activity  to  plan  strategic  projects.  It  is  though  these  projects  that 
the  business  intends  to  attain  its  strategic  goals.  Planning  strategic 
projects  is  carried-out  at  a  high  level  and  includes  the  definition  of 
such  items  as:  deliverables,  schedules,  resources,  cost,  etc.  Once  the 
planning  exercise  has  been  completed,  a  subset  of  the  developed 
strategic  project  plans  are  authorised  for  initiation.  If  selected  for 
initiation,  a  strategic  project  plan  is  further  developed  and  refined 
into  one  or  more  tactical  project  plans.  The  tactical  project  plans 
include  all  the  specific  information  that,  is  necessary  to  start-up  and 
carry-out  a  project.  The  underlying  purpose  is  to  detail  the  methods 
for  securing  the  objectives  of  the  strategy.  Finally,  authorised 
strategic  projects  will  be  controlled  based  upon  the  performance  of  the 
tactical  projects. 

A- 13  MONITOR  EFFECTIVENESS  OF  BUSINESS  STRATEGY 

During  this  activity,  the  business  strategy  is  monitored  in  two  ways, 
i.e.,  in  a  bottom-up  as  well  as  a  top-down  fashion.  As  for  bottom-up, 
an-going  tactical  projects  are  tracked  in  terms  of  their  performance. 
They  should  operate  effectively  and  attain  the  goals  that  are  outlined 
in  the  strategic  project  plans.  With  top-down,  changing  technology  and 
industry  needs  must  be  carefully  analyzed  so  that,  strategic  objectives 
can  be  modified  accordingly. 


A-0  PLAN  AND  MANAGE  STRATEGIC  INTEGRATED  INFORMATION  SYSTEM  PROJECTS 


Various  strategic  projects  may  be  initiated  by  an  enterprise  in  order 
to  acheive  strategic  objectives.  This  particular  activity  -focuses  on 
the  strategic  planning/management  that  is  associated  with  integrated 
information  system  projects. 


AO  PLAN  AND  MANAGE  INTEGRATED  INFORMATION  SYSTEM  (IIS)  EVOLUTION 
PROJECT 

This  activity  focuses  on  the  planning/management  of  the  Integrated 
Information  System  (IIS)  evolution  project.  The  objective  of  the  IIS 
project  is  to  design,  develop,  construct,  and  demonstrate  a  prototype 
that  effectively  captures,  manges,  and  distributes  key  digital  and 
graphic  technical  data  across  the  entire  life  span  of  a  commercial 
product  (e.g.,  automobile,  airplane,  etc.). 


A1  DEVLOP  IIS  EVOLUTION  STRATEGY 

This  activity  focuses  on  the  development  of  a  strategy  for  the 
evolution  of  IIS.  This  cannot  be  accomplished  without  a  thorough 
understanding  of  the  IIS  project  proposal-,  its  impact  on  the  business 
strategy  and  the  impact  of  the  project  on  business  operations.  Once 
this  has  been  determined,  a  tactical  plan  is  developed,  the  development 
is  managed  and  the  final  tactical  plan  is  approved. 


A12  EVALUATE  IMPACT  OF  IIS  EVOLUTION  PROJECT  PROPOSAL  ON  BUSINESS 
STRATEGY 

Once  the  IIS  project  proposal  has  been  interpreted,  its  impact  on  the 
overall  business  strategy  must  be  evaluated.  This  would  include  an 
examination  of  the  following:  possible  conflicts  with  the  enterprise 
mission,  policies  and  long  range  plan;  new  product/service 
character i sti cs  and  how  they  may  affect,  production,  marketing, 
resources,  etc. 


A13  EVALUATE  IMPACT  OF  IIS  EVOLUTION  ON  BUSINESS  OPERATIONS 

Factors  associated  with  the  strategic  impact  that  the  IIS  proposal  has 
on  the  overall  business  strategy  will  filter  down  to  impact  business 
operations  to  some  extent.  The  degree  of  impact  must  be  evaluated 
through  an  examination  of  apparent  changes  to  the  existing  organization 
structure,  functional  archi tecture ,  staff  skills,  system  architecture, 
information  flow  and  data  archi tecture. 


A14  DEVELOP  TACTICAL  PLAN  FOR  IIS  EVOLUTION 

This  activity  focuses  on  balancing  the  demand  for  resources  for  the  IIS 
project  with  those  for  on-going  projects. 
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This  activity  -focuses  on  the  the  de-finition  of  the  development  plan  for 
the  IIS  project.  The  development  plan  is  made  up  of  an  application 
plan,  data  plan,  service  plan,  and  resource  plan.  The  purpose  of  the 
development  plan  is  to  define  the  IIS  project  as  an  i mpl ementabl e 
subset  of  the  strategic  plan.  The  plan  is  defined  such  that  it  is 
carried-out  over  the  tactical  time  period. 


A1411  ESTABLISH  APPLICATION  PLAN 

Based  upon  key  functions  of  the  enterprise  and  existing  appl i cati ons , 
this  activity  translates  the  IIS  evolution  strategy  into  an  application 
plan.  The  application  plan  is  a  guide  to  be  used  for  all  application 
development  and  modification  of  system  requirements  that  are  to  be  met 
during  the  tactical  time  period.  The  plan  focuses  on  a  consistent 
application  architecture  so  that  the  needs  of  all  enterprise 
organisations  can  be  satisfied. 


A1412  ESTABLISH  DATA  PLAN 

Based  upon  the  application  plan  and  present  status  of  data,  this 
activity  translates  the  IIS  evolution  strategy  into  a  data  plan.  The 
data  plan  focuses  on  data  and  data  resources  that  exist  within  the 
enterprise.  It  defines  requirements  that  are  to  be  met  during  the 
tactical  time  period.  The  plan  modifies  and/or  expands  the  existing 
data  architecture  in  relation  to  the  changes  that  are  made  to  the 
application  architecture  because  of  the  IIS  evolution  project. 


A1413  ESTABLISH  SYSTEMS  PLAN 

Based  upon  the  application  and  data  plans,  the  present  status  of 
hardware,  software,  the  network,  and  the  request  for  existing  service 
modif ications,  this  activity  translates  the  IIS  evolution  strategy  into 
a  systems  plan.  The  systems  plan  is  develop  utilizing  the  results  of 
an  examination  of  various  technology  alternatives.  It  defines 
requirements  (i.e.,  new  systems  and/or  integration  of  existing  systems) 
that  are  to  be  met  during  the  tactical  time  period.  It  identifies  the 
functional  environment  for  both  application  and  data  planning.  The 
plan  expands  the  systems  architecture  in  relation  to  the  changes  that 
are  made  to  the  application  and  data  architectures  because  of  the  IIS 
evolution  project. 


A 14 14  ESTABLISH  PROJECT  FLAN 

This  activity  translates  application,  data,  and  systems  plans,  into 
well-defined  and  manageable  IIS  projects.  A  project  plan  is  defined 
and  applied  to  all  new  IIS  related  development.  The  plan  contains  a 
list  of  activities  and  tasks  that  are  defined  with  respect  to  expected 
results.  It  includes  pre-defined  milestones  which  represent  decision 
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points  in  the  project.  For  each  milestone  task,  resources  and  time  is 
estimated  so  that  reasonable  decisions  pertaining  to  results  and 
associated  risks  can  be  made.  Definitions  of  any  unique  project 
related  control  requirements  are  also  included  in  the  plan. 

Once  a  reasonable  project  plan  has  been  established,  it  must  be 
financial  justified.  This  is  accomplished  through  an  investment 
evaluation  that  estimates  the  costs  and  benefits  resulting  from  the 
implementation  and  use  of  applications,  data,  and  systems. 


A 1 42 


DEFINE  MANAGEMENT  PLAN 


This  activity  focuses  on  the  creation,  management  and  modification 
the  management  system. 


of 


A1421 


ESTABLISH  MANAGEMENT  SYSTEM  PLAN 


Using  strategic  guidance  and  an  assessment  of  the  existing  management, 
system,  this  activity  defines  a  prioritised  management  plan  to  support 
the  management  system  over  the  tactical  time  period  of  the  IIS  project. 


Ai4: 


ESTABLISH  MANAGEMENT  SYSTEM  MONITORING  PLAN 


Using  feedback  from  all  processes,  this  activity  assesses  the 
effectiveness  of  the  management  system  and  makes  sure  that  it  is 
enhanced  if  necessary.  Organi zational  performance  is  compared  against 
management  factors  to  determine  if  and  how  the  mangement  system  should 
be  modified  to  adequately  meet  the  needs  of  the  IIS  evolution  project. 


A 143 


DEFINE  SERVICE  PLAN 


This  activity  focuses  on  the  development  of  a  total  service  plan  that 
will  meet  the  needs  of  the  enterprise  over  the  tactical  time  period  of 
the  IIS  evolution  project.  The  service  plan  covers  service  marketing, 
service  level  planning,  recovery  planning,  security  planning,  and  audit 
planning . 


TO 


A1431 


ESTABLISH  SERVICE  MARKETING  PLAN 


Based  upon  the  services  to  be  offered  during  the  tactical  time  period 
of  the  IIS  evolution  project,  this  activity  establishes  who  can  use  the 
services  and  at  what  rate  they  are  to  be  charged.  Also  during  this 
activity,  market  prices  and  service  volumes  are  forcast,  and  services 
promotions  are  developed. 


A 1432 


ESTABLISH  SERVICE  LEVEL  PLAN 


Utilizing  market  prices  and  service  volume  forcasts,  this  activity 
establishes  service  agqreements  for  the  tactical  time  period  of  the 
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evolution  project.  This  includes:  recovery,  security,  auditability, 
etc.  A  preventative  maintenance  plan  and  service  support  plan  are  ale 
developed  during  this  activity. 

A 1433  ESTABLISH  RECOVERY  PLAN 

This  activity  establishes  a  plan  to  ensure  that  agreed  upon  services 
are  provided  in  case  of  system  failure. 

A 1434  ESTABLISH  SECURITY  PLAN 

This  activity  establishes  a  plan  to  ensure  that  agreed  upon  levels  of 
system  and  service  security  are  provided. 

A 1435  ESTABLISH  AUDIT  PLAN 

This  activity  establishes  a  plan  to  ensure  that  agreed  upon  levels  of 
system  and  service  auditability  are  provided. 

A 144  DEFINE  RESOURCE  PLAN 

This  activity  focuses  on  integrating  requirements  for  Development 
Planning  and  Service  Planning  into  a  workable  resource  plan  for  the  II 
evolution  project. 

A1441  ESTABLISH  CAPACITY  PLAN 

Utilising  workload  forcasts  from  the  IIS  evolution  project  and/or  from 
the  evolution  of  existing  services,  this  activity  defines  in  a  capacit 
plan  how  resoures  will  caver  the  demand.  It  also  purposes  alternative 
to  manegement  (number  of  shifts,  decreased  services,  changes  in  system 
plan,  etc.),  based  upon  the  potential  ammuunt.  of  total  workload. 

A1442  ESTABLISH  SKILLS  PLAN 

Utilising  requirements  identified  in  the  IIS  evoution  project  plan  and 
from  the  service  plan,  this  activity  defines  in  the  personnel  and  the 
education  plans  how  existing  and  planned  skills  will  meet  the  demand. 

A1443  ESTABLISH  BUDGET  PLAN 

This  activity  translates  system,  service,  project,  capacity,  personnel 
and  education  plans  into  financial  terms  and  identifies  how  funds  will 
be  obtained  and  allocated  during  the  IIS  evolution  project. 


A15  MANAGE  DEVELOPMENT  OF  TACTICAL  PLANS 


This  activity  merges  individual  plans  and  resol ves  any  imbalances.  1 
monitors  performance  against  the  total  IIS  strategy  and  determines  an 
corrective  action  that  is  necessary. 


A151  REVIEW  PLANS 


This  activity  -focuses  on  the  review  o-f  service,  project,  capacity, 
personnel,  education,  budget,  system,  application,  and  data  plans 
related  to  the  IIS  evolution  project. 


A 152  BALANCE  PLANS 


This  activity  -focuses  on  balancing  service,  project,  capacity, 
personnel,  education,  budget,  system,  applcation,  and  data  plans 
related  to  the  IIS  evolution  project. 


A 153  OBTAIN  PRELIMINARY  APPROVAL 


This  activity  -focuses  on  obtaining  preliminary  approval  -for  service, 
project,  capacity,  personnel,  education,  budget,  system,  applcation, 
and  data  plans  related  to  the  IIS  evolution  project. 


A 154  PUBLISH  PLANS 


This  activity  -focuses  on  publishing  service,  project,  capacity, 
personnel,  education,  budget,  system,  application,  and  data  plans  that 
are  related  to  the  IIS  evolution  project. 


EFFECT  IIS 


This  activity  covers  the  administration  o-f  the  IIS  project;  the 
evolution  o-f  the  IIS;  the  provisions  -for  a  systems  engineering 
environment  to  be  used  by  the  IIS;  and  the  tooling,  testware  and 
documentation  that  is  to  be  generated  over  the  tactical  time  of  the  IIS 
evolution  project. 


A21  ADMINISTER  IIS  EVOLUTION  PROJECT 


This  activity  focuses  on  the  management  and  control  of  the  IIS 

evolution  project. 


A214  MANAGE  EXECUTION  OF  IIS  EVOLUTION  PROJECT 


A2141  CONTROL  PROJECT 


This  activity  focuses  on  tracking  project  progress  against  the  tactical 
plan,  reporting  status,  conducting  project  reviews,  resolving  problems, 
and  submitting  change  requests. 


m 


fora 


m 


was 


m 


m 


S'ly; 


m 


«vr 


m. 


Si 


i'll 


ms; 


%v»\v*V(Nsv,Tiww»;«w 


A21411 


I0UUIU1MIU  U/UUUUWUIMMW'JUW  v>  un  v-j  ww  tokw 


PROVIDE  PROJECT  ASSIGNMENT  208 

During  this  activity,  tactical  plans  are  utilised  to  establish  the 
pro ject ' scope ,  leadership,  and  user  involvement  necessary  to  ensure 
success  of  the  IIS  evolution  project. 

A21412  PROVIDE  PROJECT  SCHEDULING 

During  this  activity  a  detailed  IIS  evolution  project  project  plan  is 
prepared.  The  plan  includes:  objectives,  organi z at i on ,  resources, 
tasks,  work  schedule,  and  deliverables. 

A21413  PROVIDE  PROJECT  MONITORING 

Using  the  detailed  project  plan,  this  activity  tracks  the  progress  o-f 
the  IIS  evolution  project  project  through  its  phases,  conducting 
reviews,  resolving  development  problems,  and  documenting  a  history  c.t 
its  life  cycle.  This  includes  submitting  change  requests  to  move? 
deliverables  to  the  system  inventory. 


A21414  PROVIDE  PROJECT  REQUIREMENTS  CONTROL. 

This  activity  accepts  or  rejects  requests  -for  changes  and  adjusts  the 
detailed  IIS  evolution  project  plan  accordingly.  Changes  result  from 
modified  objectives,  new  procedures,  new  technology,  or  errors  in  the- 
original  project  scope. 


A21415  PROVIDE  PROJECT  EVALUATION 

Utilizing  the  detailed  IIS  evolution  project  plan  and  project  history, 
this  activity  documents  its  completion  and  ensures  that  all  promised 
deliverables  were  actually  furnished.  It  compares  actual  and  planned 
results  and  identifies  reasons  for  variances. 


A2142  CONTROL  EVOLUTION 

This  activity  maintains  the  evolution  of  the  IIS  through  control  of 
appl ication/sof tware  development,  procurement  and  upgrade:  control  of 
hardware/f aci 1 i ty  installation  and  upgrade;  and  tun i ng /system 

bal anci ng. 


A21421  PROVIDE  APPLICATION/SOFTWARE  DEVELOPMENT  AND  UPGRADE 

This  activity  focuses  on  the  development  and  upgrade  of  applications, 
operating  systems,  and  other  support  software  that  is  utilized  by  the 

IIS. 


A21422 


PROVIDE  APPL I  ACT  I ON/SOFTWARE  PROCUREMENT  AND  UPGRADE 


This  activity  ■focuses  on  the  procurement  of  vender  developed 
applications,  operating  systems,  and  other  support  software  to  be 
modified  and  upgraded  for  use  by  the  IIS. 


A21423 


HARDWARE/FACILITY  INSTALLATION  AND  UPGRADE 


This  activity  focuses  on  the  selection,  i nstal 1  at i on ,  removal, 
modification  and  upgrade  of  IMS  hardware  and  facilities  that  are  to  be 
utilized  by  the  IIS. 


A21424 


PROVIDE  TUNING  AND  SYSTEM  BALANCING 


This  activity  tunes  resources  to  ensure  that  the  IIS  evolution  proceeds 
as  desired.  This  includes  periodic  evaluation  to  make  sure  that 
modifications  to  the  evolution  do  not  cause  undesireable  results  in 
existing  resources  and  so  that  system  balancing  can  take  place  to 
rectify  problems. 


A2 1 43- 


CONTROL  RESOURCES 


This  activity  maintains  the  flow  of  IIS  project  deliverables  and 
controls  changes  the  project  resources  resulting  therefrom. 


A21431 


PROVIDE  RESOURCE  CHANGE  CONTROL 


Using  change  requests,  this  activity  selects,  coordinates,  groups,  and 
monitors  all  changes  to  IIS  evolution  project  resources  and  procedures 
in  such  a  way  that  there  is  either  minimal  impact  on  operations  or 
minimal  risk.  It  triggers  resource  and  data  inventory  updates. 

A21432  PROVIDE  RESOURCE  AND  DATA  INVENTORY  CONTROL 

Using  change  information,  this  activity  builds  and  manages  inventories 
of  all  the  IIS  evolution  project  resources  (including  personnel  and 

f i nanci al ) . 


A2144  CONTROL  SERVICES 

This  activity  maintains  production  and  distribution  of  services  related 
to  the  IIS  evolution  project. 

A21441  PROVIDE  PRODUCTION  AND  DISTRIBUTION  SCHEDULING 

Based  upon  tactical  plans  and  inventory  related  to  the  IIS  evolution 
project,  this  activity  translates  planned  service  agreements  into  a 
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work  schedule  -for  production  and  distribution.  This  activity  also 
monitors  work  performance  and  it  deemed  necessary  modifies  the  the 
schedule  accordingly. 


A21442  PROVIDE  RESOURCE  AND  DATA  PERFORMANCE  CONTROL 


.V 


! 


Based  upon  the  work  schedule  related  to  the  IIS  evolution  project,  this 
activity  measures,  quantifies  and  reports  system  performance  levels. 

If  a  problem  situation  occurs,  a  pre-defined  corrective  action  is  taken 
to  adjusted  work  tasks  in  order  to  enhance  system  performance.  If  no 
pre-defined  corrective  action  is  available  the  PROVIDE  PROBLEM  CONTROL 
activitiy  is  initiated. 


A21443  PROVIDE  PROBLEM  CONTROL 

This  activity  determines  the  nature,  impact  and  extent  of  problems 
related  to  the  IIS  evolution  project.  Once  a  problem  has  been 
recognized  and  logged,  bypass  and  recovery  procedures  are  acti  /atcd  to 
resolve  the  problem.  This  activity  also  controls  and  reports  the 
status  of  all  problems  that  are  being  resolved. 

A21444  PROVIDE  SERVICE  EVALUATION 

This  activity  compares  performance  and  impact  of  problems  with  service 
agreements.  It  also  identifies  and  reports  reasons  for  variances  to 
users  and  management. 

A2145  PROVIDE  ADMINISTRATIVE  SERVICES 

This  activity  administers  the  financial,  personnel,  education,  and 
training  activities  that  are  required  to  support  the  IIS  evolution 
project . 


A21451  PROVIDE  FINANCIAL  ADMINISTRATION 

This  activity  applies  service  rates  to  resources  to  determine  total 
costs  applicable  to  individual  users,  accumulates  these  costs,  charqes 
the  individual  user  organi z at i on ,  and  matches  against  the  budget.  This 
activity  also  includes  maintaining  the  contractual  agreements  for 
project  work,  hardware  and  software  leasing,  and  other  supportive 
efforts. 


A21452  PROVIDE  STAFF  PERFORMANCE  TRACKING 

This  activity  tracks  staff  performance  and  reports  productivity 
associated  with  the  IIS  evolution  project. 

A21453  PROVIDE  EDUCATION  AND  TRAINING 
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ARTIFACT  1  -  SDP-C  MECHANISM/LEAF  NODE  MATRIX 
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MECHANISM  TYPE:  PERFORMANCE  ANALYSIS  TOOLS 
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MECHANISM  TYPE:  SET  ANALYSIS  TOOLS 
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MECHANISM  TYPE:  SYSTEM  DESCRIPTION  TOOLS 


MECHANISM  TYPE:  SYSTEM  DESCRIPTION  TOOLS  (conttt) 


PROTOTYPING  TOOLS  ~  SUPPORT  FOR  DEVELOPING  PROTOTYPES 
DURING  REQUIREMENTS  DEFINITION  AND  PRELIMINARY  DESIGN. 


MECHANISM  TYPE:  CONTROL  FLOW  ANALYSIS  TOOLS 
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MECHANISM  TYPE:  SPECIFICATION  LANGUAGES 


MECHANISM  TYPE:  CONFIGURATION  MANAGEMENT  TOOLS 
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APPENDIX  F 


SDP-0  Mechanism  Functionality  Classes 


ARTIFACT  3 
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ARTIFACT  3  -  SDP-0  MECHANISM  FUNCTIONALITY  CLASSES/DEFINITIONS 


DESCRIPTION/DEFINITION 

FUNCTION  MODELING 

A  method/tool  for  developing  structured  representations  of  the 
processes  performed  by  a  system  (Business  Area  or  Computer 
Application).  Function  Models  may  be  developed  using 
hierarchical  decomposition  and  object  flow  diagramming 
techniques  which,  in  addition  to  representing  processes, 
indicate  the  flow  of  objects  and/or  information  about  those 
objects  among  the  processes.  Example:  IDEF-0  Based  Tools 

INFORMATION  MODELING 

A  method/tool  for  developing  structured  representations  of  the 
kinds  of  information  required  by  a  system  and  the  interrelation¬ 
ships  among  the  kinds  of  information.  An  Information  Model 
generally  identifies  entity  classes,  attribute  classes  and  relation 

classes  in  a  normalized  form.  Example:  IDEF-1  Based  Tools. 

DYNAMICS  MODEUNG 

A  method/tool  for  developing  structured  representations  of  the 
time  sensitive  relationships  between  processes  (events)  such  as 
the  activation/deactivation  sequence,  triggers  and  constraints, 

activation/deactivation  thresholds,  volume  and  rates  of 

object  flow,  resource  consumption  per  activation  cycle  and 
conditional  paths.  Example:  IDEF-2  Based  Tools. 

STATE  TRANSITION  MODEUNG 

A  method/tool  for  developing  structured  representations  which 
show,  for  any  object,  the  allowable  states  of  the  object,  allowable 
changes  in  states  and  constraints  governing  state  changes  (such 
as  the  allowable  order  of  change)  and  reentry  to  previous  states. 

SPECIFICATION  REPRESENTATION 

A  method/tool  which  supports  specification  of  a  design  used  for 
construction  of  a  system  and/or  system  components. 

Example:  SDDL  (Software  Design  and  Documentation 

Language). 
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ARTIFACT  3  -  SDP-0  MECHANISM  FUNCTIONALITY  CLASSES/DEFINITIONS 


FUNCTIONALITY  CLASS 

DESCRIPTION/DEFINITION 

SIMULATION  ANALYSIS 

A  method/tool  used  to  construct  a  mathematical  profile  of  the 
projected  behavior  of  system  components  based  upon 
parameters  provided  through  a  Dynamics  Model  and/or  State 
Transition  Model.  Example:  IDSS  2.0  (Integrated  Decision 

Support  System) 

CODING  AND  CLASSIFICATION 

A  method/tool  which  assists  in  the  coding  and  classification  of 
system  components  based  upon  their  respective  characteristics. 
Example:  GTSS  (Group  Technology  Support  System) 

CONFIGURATION  CONTROL 

A  method/tool  which  controls  the  release  and  usability  of  system 

components  and  their  various  versions.  Example:  CCARS 

(Change  Control  and  Reporting  System)/SCCS  (Source  Code 
Control  System) 

PERFORMANCE  ANALYSIS 

A  method/too!  for  monitoring  and  tracking  the  performance  of 
implemented  system  components. 

LIFE  CYCLE  ARTIFACT  MANAGEMENT 

A  method/lool  for  capturing,  retaining  and  facilitating  the  use/ 
maintenance  of  project/system  documentation  throughout  the 

system  life  cycle.  Also  employed  to  assure  completeness  and 
consistency  of  life  cycle  artifact  content. 

DATABASE  GENERATION 

A  method/tool  which  translates  an  Information  Model  into  a 

physical  database  design  suitable  to  the  particular  Database 
Management  System(s)  used  by  a  system.  Example:  DEFINE. IT 

SOFTWARE  GENERATION 

A  method/tool  which  generates  executable  code  based  upon 
program  specifications.  Example:  TRANSFORM. 

290 


ARTIFACT  3  -  SDP-0  MECHANISM  FUNCTIONALITY  CLASSES/DEFINITIONS 


ECONOMETRIC  ANALYSIS 


A  method/tool  which  facilitates  an  analysis  of  the  economic 
impact  of  a  system  on  its  environment.  It  assists  in  analyzing 
costs  (in  terms  of  resources,  trade-offs,  etc.)  of  alternate  design 
choices  against  the  benefits  to  be  derived  from  them. 

Example:  CDEF  (Cost  Definition  System) 


CLUSTER  ANALYSIS 


A  method/tool  which  uses  algorithmic  processing  for  grouping 
system  components  into  clusters/classes  based  upon  similarity 
and/or  oommonality  of  their  respective  characteristics. 


SURVEY  SUPPORT 


A  method/tool  which  aids  in  the  construction  and  execution  of 
surveys/interviews  and  capturing  of  the  results. 


TEST  CASE  GENERATION 


A  method/tool  which  generates  test  plans,  test  data  and 
expected  results  through  the  interpretation  of  construction 
specifications  and/or  constructed  software  components. 
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TOOL  FACT  SHEET 


DESCRIPTION 

ISS-THREE  is  a  capacity  management  tool  that  integrates  the  MVS  Analyzer  and  Capacity  Planner.  The 
MVS  Analyzer,  a  mainframe  tool,  extracts,  summarizes  and  reports  on  system  activity  for  MVS/XA 
and  MVS/SP  operating  systems. 

The  Capacity  Planner  is  a  PC  based  tool  designed  to  model  any  computer  system.  It  employs  expert 
systems  techniques  to  recommend  appropriate  equipment  configurations  to  meet  specified  objectives. 
The  system  permits  "what  IT  analysis  to  compare  alternative  scenarios. 
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_ TOOL  FACT  SHEET _ 303 

REF.  f :  3  TOOL  NAME:  INFORMATION  ENGINEERING  WORKBENCH 

SOURCE:  KNOWLEDGEWARE,  INC. 

FIRST  RELEASE  DATE:  MAY  1986  CURRENT  RELEASE  LEVEL:  3.0 

APPROX.  INSTALLATIONS:  1700  PRICE  RANGE:  $7500  LESS  DISCOUNTS 


MACHINES) 

BM  PC/AT  AND 
COMPATIBLES 


OPERATING 

SYSTEM(S) 

MS/DOS 


HOST  ENVIRONMENT(S) 

DATABASE  COMMAND 

MANAGER(S)  LANGUAGE^) 


COMMUNICATION 


ASCII  IMPORT/EXPORT 


DESCRIPTION 

Based  on  James  Martin's  Information  Engineering  approach.  IEW  is  a  structured  analysis  tool  that  supports 
Function  Modeling,  Data  Modeling  and  Function/Data  Dynamics  Modeling.  Function  Modeling  graphics  are 
compatible  with  DeMarco/Yourdon  Data  Flow  Diagrams  (DFD's).  Data  Modeling  graphics  are  a  variation  of  Chen's 
Entity  Relationship  (ER)  notation  augmented  with  Martin's  P-Frames.  The  user  is  provided  with  a  selectable 
ICON  set.  Function/Data  Dynamics  are  represented  via  Martin's  Action  Diagrammer  notation.  Graphics  are 
generated  from  stored  model  descriptions,  i.e.,  a  stored  fact  base.  Rule  enforcement  via  Prolog  inference  tables 
enforces  consistency  among  levels  within  a  model,  and  among  related  models. 
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REF.#:  4  TOOL  NAME:  EXCELLERATOR 

SOURCE:  INDEX  TECHNOLOGY  CORPORATION 

FIRST  RELEASE  DATE:  AUGUST  1984  CURRENT  RELEASE  LEVEL:  1.7 

APPROX.  INSTALLATIONS:  5.000  PRICE  RANGE:  $8,400  -  $12,500 


DESCRIPTION 


EXCELLERATOR  provides  integrated  graphics  for  function  and  data  modeling,  reporting,  documentation  and 
8creerVrepoit  design  facilities  for  the  analysis  and  design  of  systems.  It  supports  four  new  graphics  developed 
for  real  time  system  design,  transformation  graphics,  state  transition  diagrams  and  block  diagrams.  It  also 
supports  two  methodologies  for  real  time  design  ( Ward  &  Millor  and  Hatley). 

EXCELLERATOR  provides  a  tool  for  creating  Data  Flow  Diagrams,  Structure  Charts,  Structure  Diagrams, 
Logical  Data  Models,  Entity  Relationships.  Data  Models  and  Presentation  Graphics. 
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REF.#:  6  TOOL  NAME:  AUTO-MATE  PLUS 

SOURCE:  LEARMONTH  &  BURCHETT  MANAGEMENT  SYSTEMS,  INC. 

FIRST  RELEASE  DATE:  SEPTEMBER  1985  CURRENT  RELEASE  LEVEL: 

APPROX.  INSTALLATIONS:  PRICE  RANGE:  $8,000 


HOST  ENVIRONMENT(S) 


OPERATING 

DATABASE 

COMMAND 

MACHINES) 

SYSTEMS) 

MANAGER(S) 

LANGUAGE^) 

COMMUNICATION 

BM  PC/AT  AND 
COMPATIBLES 

MS/DOS  3.2 

DESCRIPTION 

AUTO-MATE  PLUS  is  an  integrated  software  product  for  supporting  system  analysis,  logical  design,  relational 
data  analysis  and  physical  design  and  specifications.  The  tool  runs  on  PC  class  machines,  but  links  to 
mainframe  data  dictionaries.  AUTO-MATE  PLUS  aids  the  developer  in  prototyping  applications  screens  and 
report  formats  in  the  generation  of  IDMS/R  database  definitions.  Graphics  supported  by  the  product  include 
Data  Flow  Diagrams.  Data  Modeling,  Online  Control  Structures  (ADS/A)  and  Modular  Dependency. 
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REF.#:  7  TOOL  NAME:  LEVERAGE 

SOURCE:  D.  APPLETON  COMPANY,  INC.  (DACOM) 

FIRST  RELEASE  DATE: 

APPROX.  INSTALLATIONS: 


CURRENT  RELEASE  LEVEL: 
PRICE  RANGE: 
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TOOL  NAME:  PRECISE/IE  (cont’d.) 


•  PRECISE/TIE  defines  and  documents  detailed  specifications  for  each  of  the  projects  identified  during  the 
strategic  analysis  phase. 

e  Finally,  PRECISE/SDA  relates  the  plans  and  specifications  of  the  preceding  PRECISE/IE  phases  to  a 
specific,  efficient  technical  and  physical  solution. 


TOOL  FACT  SHEET 


310 


ft*. 

S: 

iW. 


P 

I 


DESCRIPTION 

STRADIS/DRAW  graphics  software  system  allows  for  the  creation  and  updating  of  two  dimensional 
structured  diagrams  in  a  time  sharing  environment.  System  capabilities  include  interactive  construction  of  Data 
Flow  Diagrams,  System  Structure  Charts  and  Design  Data  Flow  Diagrams 
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REF.#:  10  TOOL  NAME:  SYSTEM  DEVELOPER'S  PRO  KIT 

SOURCE:  MCDONNELL  DOUGLAS  INFORMATION  SYSTEMS  GROUP 

FIRST  RELEASE  DATE:  CURRENT  RELEASE  LEVEL:  2.0 

APPROX.  INSTALLATIONS:  PRICE  RANGE:  $2,450  •  PRO  KIT  ANALYST 

- -$600  -  DFD  DRAW 

'  $600  -  SC  DRAW 

HOST  ENVIRONMENT(S) 

OPERATING  DATABASE  COMMAND 

MACHINE(S)  SYSTEMS)  MANAGER(S)  LANGUAGES)  COMMUNICATION 

CM  PC/XT, 

IBM  PC/AT, 

3270  PC  AND 
COMPATIBLES 


DESCRIPTION 

SYSTEM  DEVELOPER'S  PRO  KIT  is  made  up  Of  three  separate  products:  PRO  KIT  ANALYST,  DFD  DRAW  and 
SC  DRAW.  PRO  KIT  ANALYST  is  an  automated  graphics  system  used  for  drawing  Data  Flow  Diagrams  which 
generates  its  own  data  dictionary  as  the  Data  Flow  Diagrams  are  created.  DFD  DRAW  is  a  graphics  software 
package  which  provides  for  the  creation  of  Data  Flow  Diagrams.  SC  DRAW  is  a  graphics  product  for  the 
development  and  maintenance  of  Structure  Charts. 
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REF.#:  13  TOOL  NAME:  GAMMA 

SOURCE:  KNOWLEDGEWARE,  INC. 

FIRST  RELEASE  DATE:  CURRENT  RELEASE  LEVEL: 

APPROX.  INSTALLATIONS:  40  PRICE  RANGE:  $182,000 


MACHINES) 


BM 


HOST  ENVIRONMENT(S) 


OPERATING 

DATABASE 

COMMAND 

SYSTEM(S) 

MANAGER(S) 

LANGUAGES) 

OOS/VSE 

IMS/DC 

VM/VMS 

MVS 

CMS/ISPF 

DL1 

TSO/ISPF 

VSAM 

CICS 

COMMUNICATION 


DESCRIPTION 

GAMMA  is  an  interactive  application  generator,  which  generates  COBOL  source  code  from  system  specifications. 
It  generates  up-to-date  documentation,  and  acts  as  a  project  management  tool.  GAMMA  development  involves 
painting  screen  and  report  layouts.  GAMMA  translates  these  screens  and  reports  into  source  code. 
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REF.#:  14  TOOL  NAME:  TELON 

SOURCE:  PANSOPHIC  SYSTEMS,  INC. 

FIRST  RELEASE  DATE:  1981  CURRENT  RELEASE  LEVEL:  1.5 

APPROX.  INSTALLATIONS:  200  PRICE  RANGE:  $130,000  -  CICS/VSAM 


$300,000  -  IMS/DC 


HOST  ENVIRONMENT(S) 

OPERATING 

DATABASE  COMMAND 

MACHINE(S) 

SYSTEM(S) 

MANAGER(S)  LANGUAGE^) 

COMMUNICATION 

BM 

CICS 

IMS/DC 

VSAM 

DESCRIPTION 

TELON  is  a  high  level  design  tool  that  addresses  the  entire  development  cycle.  It  is  an  interactive  system  for 
development  of  application  systems  for  IMS/DC,  CICS/OS  and  batch  environments.  It  is  composed  of  three 
software  modules: 

*  Design  Facility  -  Interactively  captures  design  and  programming  specifications. 

*  Application  Generator  -  Generates  source  code  in  COBOL  or  PU1 

*  Modeling  and  Test  Facility  -  Provides  a  simplified  environment  for  modeling  and  assists  in  program  testing 

TELON's  automated  documentation  feature  provides  the  ability  to  summarize  design  information  and  track  the 
use  of  databases. 
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REF.*:  15  TOOL  NAME:  TRANSFORM 

SOURCE:  TRANSFORM  LOGIC  CORPORATION 

FIRST  RELEASE  DATE: 

CURRENT  RELEASE  LEVEL: 

APPROX  INSTALLATIONS: 

PRICE  RANGE:  $225,000 

HOST  ENVIRONMENT(S) 

OPERATING 

DATABASE 

COMMAND 

MACHINE(S) 

SYSTEM(S) 

MANAGER(S) 

LANGUAGES) 

COMMUNICATION 

IBM 

CICS 

IMS  DB^DC 

MVS 

VSAM 

DESCRIPTION 


TRANSFORM  generates  structured  COBOL  programs  from  non-procedural  design  input.  A  dictionary  provides 
revision  control  over  design  elements  and  provides  audit  trails  of  their  use.  The  Screen  Painter  Facility  allow 
tor  quick  specification  of  screen  layouts.  On-line  system  documentation  provides  a  current,  accurate  and 
complete  representation  of  the  application  programs 
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REF.#:  16  TOOL  NAME:  STRATEGIC  SYSTEMS  PLANNING 

SOURCE:  HOLLAND  SYSTEMS  CORPORATION 

FIRST  RELEASE  DATE:  1 98 1  CURRENT  RELEASE  LEVEL: 

APPROX.  INSTALLATIONS:  PRICE  RANGE:  $80,000 


HOST  ENVIRONMENT(S) 

OPERATING  DATABASE  COMMAND 

MACHINES)  SYSTEMS)  MANAGER(S)  LANGUAGES)  COMMUNICATION 


DESCRIPTION 

Strategic  Systems  Planning  (SSP)  helps  develop  an  information  strategy  for  the  Enterprise.  Using 
an  Enterprise  model  and  the  analysis  capabilities  of  SSP,  an  information  strategy  can  be  developed  from  a 
top  down  perspective.  SSP  can  be  used  only  with  the  Holland  Strategic  Systems  Planning  Methodology, 
although  aspects  of  it  are  compatible  with  IBM's  Business  Systems  Planning  (BSP)  and  James  Martin's  Strategic 
Data  Planning  Methodology. 

SSP  supports  the  identification  and  analysis  of  common  information  needs  among  Enterprise  processes,  and 
employs  function  modeling  and  Affinity  Analysis  techniques 
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TOOL  NAME:  PACBASE  (cont'd.) 

The  Specifications  Dictionary,  the  focal  point  for  all  PACBASE  operations,  is  an  information  management 
system  used  to  collect,  store  and  maintain  all  information  describing  the  system,  including  processing  rules, 
data  elements,  data  structure  definition  and  relationships,  documentation  and  screen  report  layouts. 

The  Specifications  Dictionary  Manager  is  a  production-quality  database  management  system.  The 
Specifications  Dictionary  Manager's  unique  features  include:  journaling  of  dictionary  entries,  integrity  controls 
that  ensure  database  consistency  and  recovery  in  the  event  of  a  system  failure,  multi-user  access  to  concurrent 
use  of  specifications  from  higher  Ibraries,  library  management  to  provide  effective  data  organization,  and 
versioning  for  the  formal  control  of  application  releases. 

The  Application  Development  Workbench  provides  integrated  facilities  for  data  modeling,  database 
descriptions,  prototyping,  program  design,  report  composition,  screen  design  and  documentation  entry. 

PACBASE  Program  Generators  create  all  of  the  operational  components  of  the  system,  including  on-line  and 
batch  programs,  screen  maps,  database  descriptions  and  error  messages.  All  processing  logic  is  generated 
automatically  from  the  specifications  stored  in  the  dictionary,  so  no  programming  exits  need  to  be  coded.  And, 
if  needed,  special  user  routines  can  be  added  with  the  PACBASE  Structured  Code  facility,  or  you  can  use 
COBOL  directly. 

The  PACBASE  Table  Manager,  PACTABLE,  organizes  and  manages  all  table  information  without  programming 
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TOOL  NAME:  APS  (cont’d.) 

•  The  APS  DB/DC  product  group  automates  the  generation  of  programs  for  a  variety  of  DB  and  TP 
environments.  These  products  are  tightly  integrated  with  IBM's  DB/DC  offerings  such  as  CICS,  IMS/DC 
and  ISPF  data  communications  environments  accessing  DB2,  DL1  and  IMS  databases  and  VSAM  files 
Additionally,  APS  DB  products  provide  interfaces  to  IDMS  and  DatacomrrVDB. 

•  The  APS  MAINTENANCE  product  group  accepts  existing  database  and  screen  code  and  populates  the 
APS  dictionary. 

•  The  APS  DICTIONARY  group  is  the  central  repository  for  the  APS  Development  Center.  It  provides  support 
for  the  management  of  application  system  entities,  and  for  JCL  and  document  generation. 
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REF.  #:  20 


TOOL  NAME:  MAZDAMON 


SOURCE:  UCCEL 

FIRST  RELEASE  DATE:  1 983 

APPROX  INSTALLATIONS:  75 


CURRENT  RELEASE  LEVEL:  3  0 
PRICE  RANGE:  $30,000  -  $42,000 


HOST  ENVIRONMENT(S) 

OPERATING  DATABASE  COMMAND 

MACHINES)  SYSTEM(S)  MANAGER(S)  LANGUAGES) 

BM  TSO/SPF  IMS 


COMMUNICATION 


VTAM 


DESCRIPTION 

MAZDAMON  is  a  measurement  device  which  monitors  MVS  networks  and  provides  data  for  the  effective 
management  of  network  performance  and  precise  measurement  of  end  user  response  time. 
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REF.  #:  21  TOOL  NAME:  DEFINE.IT 

SOURCE/LOCATION :  SOLION,  INC 

FIRST  RELEASE  DATE:  CURRENT  RELEASE  LEVEL:  1.0 

APPROX  INSTALLATIONS:  15  PRICE  RANGE:  $4750  LESS  DISCOUNTS 


HOST  ENVIRONMENT(S) 

MACHINES) 

OPERATING 

SYSTEM(S) 

DATABASE 

MANAGER(S) 

COMMAND 

LANGUAGE^) 

COMMUNICATION 

MICRO-VAX 

VMS 

ORACLE 

SQL 

CONVERGENT 

UNIX 

ORACLE 

SQL 

IBM/XT  +  AT 

AND  COMPATIBLES 

MS/DOS 

ORACLE 

SQL 

DESCRIPTION 


DEFINE.IT  is  a  tool  which  supports  use  of  the  IDEF-1  Information  Modeling  approach.  It  contains  adequate 
definition  of  Entity  Class.  Attribute  Class  and  Relation  Class  characteristics  to  allow  automatic  generation  of 
SQL  build  commands  and  the  corresponding  ORACLE  Database  to  support  system  prototyping  The  product 
disallows  database  generation  if  the  model  is  incomplete  or  does  not  adhere  to  IDEF-1  rnles.  DEFINE.IT 
graphics  conform  to  IDEF-1  notation. 
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REF.#:  22  TOOL  NAME:  INFORMATION  MANAGEMENT  FACILITY 

SOURCE:  BOOLE  &  BABBAGE 

FIRST  RELEASE  DATE:  CURRENT  RELEASE  LEVEL: 

APPROX.  INSTALLATIONS:  PRICE  RANGE: 


HOST  ENVIRONMENT(S) 


OPERATING 

DATABASE 

- - 

COMMAND 

MACHINES) 

SYSTEM(S) 

MANAGER(S) 

LANGUAGES) 

COMMUNICATION 

BM 

IMSA/S 

DESCRIPTION 

The  IMF  product  family  provides  tools  for  analyzing,  monitoring,  managing,  reporting  and  accounting  for 
transaction  processing  in  IMSA/S  environments.  Together,  the  seven  products  in  the  IMF  product  line  provide 
a  complete  IMS/VS  performance  management  system.  They  provide  the  functions  of  operational  control, 
transaction  flow  analysis,  bottleneck  detection,  service  level  surveillance,  resource  surveillance,  transaction 
activity  profiles  and  cost  and  usage  allocation. 
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REF.#:  25  TOOL  NAME:  PACII 

SOURCE:  AGS  MANAGEMENT  SYSTEMS 
FIRST  RELEASE  DATE:  1 979 
APPROX.  INSTALLATIONS:  2000  (OVERALL) 


CURRENT  RELEASE  LEVEL:  5.3  (IBM) 
PRICE  RANGE:  $47,000 


MACHINE(S) 


HOST  ENVIRONMENT(S) 

OPERATING  DATABASE  COMMAND 

SYSTEM(S)  MANAGER(S)  LANGUAGES) 


COMMUNICATION 


DESCRIPTION 

PAC II  is  a  comprehensive  project  management  tool  which  provides  the  following  functions: 

•  Planning 

•  Progress  Tracking 

•  Budgeting 

•  Project  Monitoring 

•  Project  Simulation 

•  Project  Charge -back 

•  Scheduling 

•  Change  Management 

•  Critical  Path  Analysis 

•  Reports 

•  Skill  Scheduling 

•  Graphics 

•  Resource  Tracking 

•  Earned  Value-performance  Measurement 
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REF.  f :  26 
SOURCE:  ABVENT 
FIRST  RELEASE  DATE: 


APPROX.  INSTALLATIONS: 


TOOL  NAME:  BLUE/60  THE  DATA  MODELER 


CURRENT  RELEASE  LEVEL: 
PRICE  RANGE:  $1,495 


MACHINE(S) 

MACINTOSH 


HOST  ENVIRONMENT(S) 

OPERATING  DATABASE  COMMAND 

SYSTEMS)  MANAGER(S)  LANGUAGES) 


COMMUNICATION 


DESCRIPTION 

BLUE/60  THE  DATA  MODELER  is  a  tool  which  facilitates  the  creation  and  maintenance  of  : 

•  Data  Models 

•  Entity-relation  Diagrams 

•  Data  Dictionary 

•  Automatic  Version  Number  Creation 

•  Integrated  Text  Editiors 
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REF.*:  27  TOOL  NAME:  LOGISCOPE 

SOURCE:  VERILOG 

FIRST  RELEASE  DATE: 

CURRENT  RELEASE  LEVEL: 

APPROX.  INSTALLATIONS: 

PRICE  RANGE: 

MACHINE(S) 

HOST  ENVIRONMENT(S) 

OPERATING  DATABASE  COMMAND 

SYSTEM(S)  MANAGER(S)  LANGUAGES) 

COMMUNICATION 

APOLLO 

DOMAIN 

DEC 

VMS 

IBM 

VM/CMS,  MVS  XA 

SUN 

UNIX 

CDC 

NOS  VE 

DPS8 

MOLOCS 

DESCRIPTION 

LOGISCOPE  is  a  software  quality  analysis  tool.  It  can  be  used  during  the  basic  software  development  tasks: 
design,  coding,  unit  testing  and  integration  testing. 


LOGISCOPE  was  designed  to  provide: 

•  static  analysis  of  the  complexity  of  a  program 

•  dynamic  analysis  of  the  test  coverage 
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REF.*:  28 
SOURCE:  VERILOG 
FIRST  RELEASE  DATE: 


APPROX.  INSTALLATIONS: 


TOOL  NAME:  ASA 


CURRENT  RELEASE  LEVEL: 
PRICE  RANGE: 


MACHINE(S) 


APOLLO 


HOST  ENVIRONMENT(S) 

OPERATING  DATABASE  COMMAND 

SYSTEM(S)  MANAGER(S)  LANGUAGES) 


COMMUNICATION 


DESCRIPTION 

ASA  is  a  tool  which  provides  for  the  creation  of  the  following  in  the  applications  development  process: 

•  State  Machine  Graphs 

•  State  Transition  Tables 

•  IDEF  Diagrams 

•  Dictionary 

•  Test  Suites 

•  Complexity  Analysis 

•  Simulations 

•  Semantic  Verification 
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REF.*:  29  TOOL  NAME:  TAGS 

SOURCE:  TELEDYNE  BROWN  ENGINEERING 
FIRST  RELEASE  DATE: 

APPROX.  INSTALLATIONS:  40  US 


CURRENT  RELEASE  LEVEL:  2  7 
PRICE  RANGE: 


DESCRIPTION 

TAGS  provides  a  facility  for  the  automated  definition,  design,  documentation,  testing  and  maintenance  of 
software  systems.  TAGS  includes  the  10RL  language  and  tools,  such  as: 

•  Storage  and  Retrieval  Tool  -  manages  design  process  entities 

•  Diagnostic  Analyzer  •  locates  construction  errors 

•  Configuration  Management  -  version  control 

•  Simulation  Compiler  -  executes  IORL 

•  Analysis  Library  •  allows  engineering  &  management  access 

•  Document  Processor  -  integrates  text  &  graphics 
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HOST  ENVIRONMENT(S) 

OPERATING 

DATABASE  COMMAND 

MACHINE(S) 

SYSTEMS) 

MANAGER(S)  LANGUAGES) 

COMMUNICATION 

TBE  300  *\ 
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REF.*:  30 
SOURCE:  AO  CAD 
FIRST  RELEASE  DATE: 


APPROX.  INSTALLATIONS: 


TOOL  NAME:  STATEMATE  1 


CURRENT  RELEASE  LEVEL:  BETA  SITE  IN  US 
PRICE  RANGE:  $10,000  •  $50,000 


MACHINES) 


HOST  ENVIRONMENT(S) 

OPERATING  DATABASE  COMMAND 

SYSTEM(S)  MANAGER(S)  LANGUAGES) 


COMMUNICATION 


DESCRIPTION 

STATEMATE  1  is  a  comprehensive  systems  development  tool  which  provides  the  following  functions: 

•  Specification 

•  Design  and  analysis  of  real-time  systems 

•  State  Charts 
e  Activity  Charts 

•  Module  Charts 

•  Simulation  Tools 

•  Management  Tools 

•  Analysis  Tools 
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REF.#:  31 


TOOL  NAME:  COSTAR 


SOURCE:  SOFTSTAR  SYSTEMS 
FIRST  RELEASE  DATE:  AUGUST  1 986 
APPROX.  INSTALLATIONS:  50 


CURRENT  RELEASE  LEVEL:  1  20 
PRICE  RANGE:  $400  -  $800 


MACHINE(S) 


IBM  PC 


HOST  ENVIRONMENT(S) 

OPERATING  DATABASE  COMMAND 

SYSTEM(S)  MANAGER(S)  LANGUAGES) 

MS-DOS 


COMMUNICATION 
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DESCRIPTION 

COSTAR  is  a  tool  which  provides  for  the  implementation  of  Boehm's  COCOMO  estimating  technique  cost, 
effort  &  staffing  for  L-C  phases. 
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Cycle  Usage  /  SDP-0  Class 
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